What Is Open Data?

Open data is simply data that anyone can access, use, and share, provided appropriate safeguards around privacy and confidentiality are in place.

In the UK, open data is published across government, the NHS, and the wider public sector. One of the main entry points is data.gov.uk, the UK government’s central open data portal. It hosts nearly 25,000 datasets from central government departments, local authorities, and other public sector bodies, providing a single place where analysts, researchers, journalists, and developers can discover and access public data.

Healthcare is a major contributor to this ecosystem. The NHS publishes a substantial volume of statistical outputs and datasets each year through its official statistics programme. More than 250 statistical publications are produced annually, most of which include underlying datasets that allow analysts to explore patterns in healthcare activity, prescribing, service performance, and population health outcomes.

Licensing plays a critical role in making open data usable. Most UK public sector datasets are released under the Open Government Licence (OGL), which allows anyone to copy, analyse, adapt, and reuse public sector information - including for commercial purposes - provided the source is acknowledged. Some datasets are also released under Creative Commons licences such as CC‑BY, which operate on similar principles of open reuse with attribution.

Principles for Publishing Open Data

If open data is to reach its full potential, it must be published thoughtfully. Releasing a dataset alone is not enough; it must also be accessible, understandable, and usable. The following principles help define what good open health data looks like.

Case Study: OpenPrescribing and NHS Prescribing Data

One of the clearest demonstrations of the impact of open health data is OpenPrescribing, developed by the Bennett Institute for Applied Data Science at the University of Oxford.

The platform is built entirely on openly published NHS prescribing datasets. Each month, the NHS releases detailed anonymised data on medicines prescribed by general practitioners across England through the English Prescribing Dataset. More recently, transparency has expanded further with the publication of the Secondary Care Medicines Dataset, which provides similar insights into hospital prescribing.

These datasets are extremely large. Each monthly release contains tens of millions of rows describing which medicines were prescribed, where they were prescribed, and the associated costs to the NHS.

OpenPrescribing transforms this raw data into a searchable, interactive platform that allows clinicians, commissioners, researchers, and analysts to explore prescribing patterns across practices, regions, and time.

The platform integrates prescribing data with reference datasets such as the NHS Dictionary of Medicines and Devices, enabling medicines to be grouped and analysed in clinically meaningful ways. Users can examine prescribing variation, identify opportunities to improve prescribing practices, and understand how prescribing behaviour differs across the health system.

Importantly, OpenPrescribing is more than a visualisation tool. It provides actionable insights that clinicians and healthcare organisations can use to improve prescribing decisions. Research from the OpenPrescribing team has demonstrated significant variation in prescribing behaviour across the NHS, often highlighting opportunities for safer or more cost‑effective prescribing.

The impact has been substantial. Analyses based on these open datasets have identified prescribing practices that cost the NHS millions of pounds unnecessarily each year. By highlighting these patterns and providing tools to address them, OpenPrescribing has supported changes in prescribing behaviour that have led to significant savings while maintaining high standards of patient care.

This is a powerful example of what happens when open data is combined with thoughtful analytics and accessible tools. The NHS publishes the data, researchers build platforms that make it interpretable, and clinicians use those insights to improve practice.

None of this would have been possible without the NHS publishing the underlying prescribing data in the first place. OpenPrescribing demonstrates how open health data can move beyond transparency and become a catalyst for real‑world change in clinical practice and health system efficiency.

Closing Thoughts

Open data is not just a technical exercise; it represents a cultural commitment to transparency, collaboration, and shared learning.

When data is published openly, researchers, clinicians, journalists, and analysts can ask new questions of the health system. Analyses can be reproduced, methods scrutinised, and insights generated beyond the institutions that originally collected the data.

For health analytics, reproducibility is essential. Policies, interventions, and resource allocation decisions often rely on quantitative analysis. When the underlying data is open, analyses can be independently verified, improved, and extended. This leads to stronger evidence, faster innovation, and greater accountability across the health system.

Ultimately, open data is a public good. It deepens our understanding of how health systems function and provides the foundation for better, evidence‑based decision‑making.

Finally, a heartfelt thank you to the thousands of analysts, statisticians, and data professionals across the NHS and wider public sector who prepare, quality‑assure, and publish these datasets. Their work often happens quietly behind the scenes, but its impact is profound. By making data accessible to the wider world, they enable research, accountability, and innovation that ultimately improves health systems for everyone.

Motivation: bridging the gap between manual audits and AI

In the NHS we often talk about AI, but most analysts still rely on spreadsheets and manual review. I wanted to build something that sits between those two worlds automated enough to scale, transparent enough to be trusted, and light enough to run on an NHS desktop.

The use case is clear: radiology reports describe a patient’s imaging findings in natural language. For many analytical tasks such as population-level analytics, safety monitoring, or predictive modelling we only need to know which findings were mentioned and whether they were present or absent.

Yet standard keyword searches can’t tell us that. For example, a report stating

“The lungs are clear without focal consolidation, pleural effusion or pneumothorax.”

contains the words consolidation, effusion, and pneumothorax, but all three are absent. A purely lexical match would incorrectly record them as present. Context understanding is therefore essential for accuracy.

That problem distinguishing what was said from what was meant became the centrepiece of my work and as can be seen in Figure 1 below which highlights the architectural design of my pipeline.

Designing a contextual extractor

The extractor works in two stages:

1. Entity detection using simple but highly tuned dictionaries of anatomical and observation terms.
2. Context interpretation that determines whether each observation is present, absent, or uncertain based on nearby cue phrases.

anatomy_terms <- c("lungs", "pleura", "heart", "mediastinum", "diaphragm")

observation_terms <- c(
  "consolidation",
  "pleural effusion",
  "pneumothorax",
  "opacity"
)

context_triggers <- list(
  pre_neg = c(
    "no",
    "without",
    "free of",
    "absent",
    "negative for",
    "not seen",
    "lack of"
  ),
  post_neg = c("ruled out", "excluded"),
  pre_uncert = c(
    "possible",
    "possibly",
    "likely",
    "cannot exclude",
    "suspicious for",
    "consistent with",
    "in keeping with",
    "questionable",
    "equivocal"
  ),
  post_uncert = c(
    "may represent",
    "may reflect",
    "could represent",
    "could reflect",
    "suggesting",
    "suggests",
    "suggestive of",
    "compatible with"
  ),
  terminate = c("but", "however", "yet", "although", "except", "though"),
  pseudo_neg = c(
    "no change",
    "no interval change",
    "no significant change",
    "no appreciable change",
    "no substantial change"
  )
)

assign_context_certainty_sentence <- function(sent_text, ents_sentence_df) {
  # detect negation/uncertainty cues and adjust certainty labels
}

Extracting the right sections

To minimise false positives, the extractor first isolates only the FINDINGS and IMPRESSION sections of each report, ignoring the INDICATION text that typically contains referral questions (“rule out pneumonia”).

By focusing on the interpretive segments, the algorithm analyses the clinician’s diagnostic statements rather than their initial hypotheses.

Testing on the MIMIC-IV dataset

To validate performance, I randomly sampled 100 radiology reports from the MIMIC-IV corpus, which contains de-identified hospital data approved for research use.

Each file was read, processed, and converted into a structured tibble showing entity text, entity type, certainty, and character positions.

As seen in Table 1 below the radiology report processed through the extractor produces a structured table where every detected entity is recorded as a separate row.

For example, the report in Table 2 below:

“No focal consolidation is seen. There is no pleural effusion or pneumothorax. The cardiac and mediastinal silhouettes are unremarkable.”

This confirmed the contextual logic was functioning as intended the algorithm recognised the mentions but correctly classified them as absent.

Handling complexity and edge cases

Designing a rule-based system is not without trade-offs. Radiology language can be subtle: phrases such as “cannot exclude pneumonia” or “features may represent atelectasis” require careful scope handling. I incorporated both pre- and post-modifiers to ensure flexibility, but there remain limitations around nested clauses (“no change in the previous pneumothorax”) and conditional statements (“if present, may represent infection”). These could be addressed later with dependency parsing or a hybrid model, but the goal here was to stay lightweight and interpretable something any NHS analyst could audit and understand. Another consideration was sentence boundary detection. I used the stringi package to identify sentence offsets, which preserves character indices for later reconciliation with structured EHR tables. This proved more reliable than tokenisers that lose positional information.

Performance and scalability

Because this workflow uses only base R and string-processing libraries (stringr, stringi, dplyr), it scales linearly with text length and can comfortably process tens of thousands of reports on a standard NHS laptop. There are no GPU or internet requirements, which makes it ideal for hospital-based servers where outbound connections are restricted.

While models like spaCy or transformer-based approaches such as BioBERT can achieve higher recall on complex linguistic patterns, they require substantial infrastructure and often cannot run in the secure NHS network environment. This workflow therefore fills a critical niche: interpretable, deployable, and compliant.

Integration possibilities

The structured output from this method essentially a long table of findings with certainty labels can feed into SQL databases, Power BI dashboards, or R Shiny apps. For example, analysts could summarise all radiology mentions of pneumonia marked as “present” across an entire hospital trust, or measure how often “pleural effusion” was reported in specific cohorts. The same pattern could also be adapted to ambulance ePCR narratives, mental-health crisis notes, or pathology reports.

Code availability

Full code is publicly available in my GitHub account.

What do I mean by QA?

Quality work is about how we build models. Choosing appropriate methods, writing clean code and making sure everything is reproducible.

Quality assurance, on the other hand, is about building trust. It ensures the right processes are followed, results are checked, and outputs are credible and interpretable.

Why does QA matter?

Public organisations often rely heavily on models to make decisions. If a model has errors, unrealistic assumptions, or poor documentation, it can result in wasted resources, bad decisions and loss of public confidence.

The National Audit Office (NAO) found¹ that common problems include:

• Poor data or unrealistic assumptions
• No uncertainty or sensitivity testing
• Weak documentation and governance

Our model influences hospital planning across the NHS, so it’s vital that people can trust it.

What was missing?

Quality assurance effort should be appropriate to the risk associated with the intended use of the analysis

To find the missing pieces, I turned to existing guidance across governement and auditing organisations:

• Framework to review models, NAO
• HM Treasury’s AQuA book
• Quality assurance of models: a guide for audit committees, NAO
• The Department for Energy Security & Net Zero (DESNZ) and Department for Business, Energy & Industrial Strategy (BEIS) Modelling Quality Assurance tools and guidance
• Duck book

Turns out, we were already doing a lot of what they recommend:

All our code was version-controlled, so we already had a change log. We maintained a Quarto website with user guidance, and wrote documentation alongside the code, which served as our technical guide.

The main pieces missing were a QA plan and a QA log.

Not another spreadsheet

A QA plan is simply a list of the tasks you intend to do to improve the quality of your model.
A QA log is a record of what you’ve already done, who did it, and when they did it.

I scoured the internet looking for examples from other organisations. Almost everything I found was in spreadsheets.

The most comprehensive example I came across was from the Department for Energy Security and Net Zero (DESNZ) in their Quality Assurance (QA) tools and guidance.
However, the templates were mostly designed for Excel-based models and still just big, colour-coded spr.jpgeadsheets.

My heart sank at the thought of having to manage QA with an ugly spreadsheet. There had to be a better way.

GitHub to the rescue

Our team was already using Git and GitHub for the model code and had just started experimenting with using GitHub projects for planning.

So I thought: what if we used a GitHub project for our QA plan and log too?

I set up a new GitHub project with two views:

• Open issues ➡️ QA plan
• Complete issues ➡️ QA log

Then I browsed our repositories and added any quality assurance related issues to the board.

Our model spans multiple repos, mostly public, but some private. The project board handles this seamlessly, showing public issues to everyone and private ones only to those with access.

I also decided to add labels to the QA issues, based on the QA type.

• 📝 Documentation
• 🗃️ Data & Assumptions
• 🧪 Verification
• ❓Validation
• 📁 Structure & Clarity

People² often get verification and validation muddled up. Verification checks that the model solves the equations correctly. Validation is checks that it’s solving the right equations.

QA in practice

Now, whenever I’m working on something QA related, I simply add it to the project board.

When we prepare our monthly model releases, we use a GitHub issue template work through a release QA checklist.

Every six months, I also do an internal QA review using another issue template.

Remove the friction

This works because QA happens where the work happens. Our developers already live in GitHub. Asking them to open a spreadsheet every time they make a model improvement just doesn’t fit how our team works. But asking them to add metadata to an issue they’re already working on, does.

Instead of a static row in an abandoned spreadsheet, each QA item has its own discussion thread, links to relevant code or analysis, and version history.

QA as a habit, not a chore

Creating and maintaining a strong culture of quality assurance is vital for ensuring analysis is robust and of a high quality. The AQuA book.

QA isn’t about ticking boxes. It’s about building trust.

There’s still plenty more to do, but moving our QA plan into GitHub has made QA part of daily coding, not an extra task at the end.

If you’ve found other ways of managing QA (without the colour-coded spreadsheets!), I’d love to hear from you.

Collaboration for scalable analytics projects – some recipes for success

Finding effective ways for NHS analysts to collaborate across organisational boundaries can be a challenge. Aligning the different skills, experience, tooling and capacity of each contributor while still meeting project deadlines is not always straightforward. Moreover, the relative lack of scalable analytics efforts to date has meant that work has naturally resided in separate NHS organisations, each developing separate models and tools. However, this way of working is especially unsatisfactory for products intended to be scalable across the NHS. Developing such a product in isolation risks ‘overfitting’ it to the particular circumstances of one area: from a customer perspective, this could mean considering only the problems and questions existing in that trust or ICS; and from a technical perspective, this could mean considering only data structures or data quality issues bespoke to that area. All this can significantly limit the level of generalisability required. Here, we describe some ways that have worked which we believe have been key for the RTT Planner project to reach its potential:

Measuring success

Success is often measured by impact. Ultimately, the team want the tool to contribute to bringing down the size of waiting lists and help local teams meet patient requirements within shorter timescales. Anyone involved in waiting list management will say that getting there takes time and there is no silver bullet. The first step on that journey which the tool supports is to simplify the complexities around the dynamics of the waiting list to allow local teams to understand how the planning choices they make are likely to impact the waiting list size and shape. The next niche the tool fills is to allow different levels of organisations to agree to plans using the same software and data, enabling better joint working.

Unfortunately, the team haven’t worked out a way to track the usage of the tool – though the growing development backlog resulting from user demands is a sign that activity is high.

The simple and explainable methods alongside the accessible and free tool means that the team have reached audiences of the hundreds through local and national webinars. The methods have also sparked an interest from Number 10 and the Cabinet Office to support their waiting list management policy activities. With the next planning rounds underway, the team have been in conversations with trusts to compare locally derived plans with tool outputs. Our hope is that these conversations can help local teams build trust in the tool’s results and will lead to teams using the tool for planning rounds.

Concluding remarks and future plans

The output of this collaboration is the RTT Planner tool.

The tool was initially released in May 2025 to our South West stakeholders, though the tool has national coverage and can be used to model any trust or region in England. Continued conversations with local teams have made it clear what developments the tool needs to enable incorporation into regular, local usage. The stakeholder engagement in the project and willingness to guide the development of the tool has helped make it as useful as possible. This collaborative approach gives us the best chance of producing a successful tool that can support Trusts, ICBs and central teams to meet waiting list targets in the longer term and enable patients to have a better elective experience of the NHS.

The project still has a long way to go to cover all the planning needs expressed by our stakeholders – with the major one being how the tool can bridge the gap between planning and operational needs. The progress made to date, and the engagement that we have received, provides a great template for future at-scale projects. This should be a major consideration for the future of analytics in the NHS. Many analytical challenges are not unique to a particular organisation and can be solved once for all. This project was only feasible because of the excellent, detailed public data that have been published for over 10 years. With the emergence of centralised data platforms, such as the Federated Data Platform, the NHS must strategically move towards more efficient ways of working. Adopting open practices, multi-disciplinary teams and collaborative techniques, as described in this blog, is a sure way of achieving this.

We would like to mention and thank those that have contributed to this project. The development team were Seb Fox and Rich Wood (BNSSG ICB), Simon Wellesley-Miller and Euan Ives (NHS England SW), Nick Cooper (Gloucestershire ICB/Gloucestershire Hospitals NHS Foundation Trust), Richard Blackwell (Health Innovation South West) and Claire Rudler (Devon ICB). The trusts that have contributed were Royal Devon University Healthcare, Torbay and South Devon, Dorset County Hospital, University Hospitals Bristol and Weston, Royal Cornwall Hospitals, University Hospitals Plymouth and North Bristol Trust. ICBs that have contributed were BNSSG, Devon, Gloucestershire, Cornwall and Dorset. We are now working with The Strategy Unit, Nottingham University Hospitals, Bradford Teaching Hospitals and Professor Neil Walton, from Durham University to develop the tool further.

Introduction

Have you ever found yourself in “commit hell” with a tangled Git history? It happens to the best of us! When you’re working on a project, it’s easy to create many small, redundant commits. This can make it difficult for you and your collaborators to understand the progression of your work.

What’s the Difference Between merge and rebase?

Think of a project’s commit history as a timeline.

• git merge combines branches by creating a new merge commit. It’s like adding a new chapter to a book without editing the old ones. This can lead to a “tangled” history with multiple branching paths.

• git rebase moves or combines a sequence of commits to a new starting point. It’s like rewriting and polishing a draft to make the story flow better. It creates a cleaner, linear history that’s much easier to read.

A Practical Use Case: Cleaning Up Commits

Let’s imagine you’ve been working on a new feature for your analysis, and you’ve made several small commits:

1. “feat: add patient ID column”
2. “fix: corrected patient ID”
3. “temp: working on EDA”
4. “feat: EDA for patient demographics”

These commits are all related to a single logical feature. We can use git rebase to squash them into a single, meaningful commit.

git rebase -i HEAD~4

git rebase -i main

pick a46f23b feat: add patient ID column
pick b71a5c1 fix: corrected patient ID
pick 8c9e0d1 temp: working on EDA
pick 3d4b6c8 feat: EDA for patient demographics

pick a46f23b feat: add patient ID column
squash b71a5c1 fix: corrected patient ID
squash 8c9e0d1 temp: working on EDA
squash 3d4b6c8 feat: EDA for patient demographics

feat: Add patient demographics EDA

- Added patient ID column with validation
- Implemented exploratory data analysis for patient demographics  
- Includes data cleaning and initial visualizations

On branch example
Your branch and 'origin/example' have diverged,
and have 6 and 2 different commits each, respectively.
  (use "git pull" to merge the remote branch into yours)

git push --force-with-lease

The Golden Rule of Rebase

⚠️ Never rebase commits that have been pushed to a shared repository.

This is the most important rule to remember. Rebasing rewrites commit history by changing commit hashes. If you rebase commits that others have already pulled, you’ll create divergent histories that are difficult to reconcile.

Safe to rebase:

• Local commits that haven’t been pushed yet
• Feature branches that only you are working on
• Commits on your personal fork before creating a pull request

Never rebase:

• The main or master branch
• Any branch that others have pulled from
• Commits that have been pushed to a shared repository

RStudio tip: In the Git pane, you can see which commits have been pushed (they appear differently from unpushed commits), helping you follow the golden rule safely.

Troubleshooting in RStudio

If something goes wrong during rebase:

1. Don’t panic! Git keeps a history of all operations

2. In RStudio’s Terminal, you can undo the rebase:

   git reflog
   git reset --hard HEAD@{1}

3. The Git pane will refresh to show your original commit history

4. Your R files remain safe - rebase only changes commit history, not your actual code

Before rebasing, always:

• Ensure your working directory is clean (no uncommitted changes in the Git pane)
• Make sure you’re on the correct branch
• Consider making a backup branch: git branch backup-branch-name

Conclusion

git rebase is a powerful tool for maintaining a clean and clear commit history, which in turn leads to better collaboration and more robust data science projects. By using it to squash your smaller, work-in-progress commits, you can ensure that your project’s history is a readable and accurate record of your progress. It’s a key practice for any data scientist aiming for reproducibility and a professional workflow.

Curating the product backlog

This is probably my favourite thing about Positron. The GitHub interface in RStudio was ok, but I still found myself using the command line, which felt like it interrupted my flow of work to a degree. Positron provides for the ability to never have to leave the IDE. Once you have authenticated your GitHub account in Positron, you can click the GitHub icon in the activity panel to see all the pull requests and issues for that repo. You can create PRs from that menu too – it’s all self-explanatory and works really well. Clicking on one of your repo issues will also open it as an additional tab in the editor pane, and you can interact with it there just as you would at github.com! No need to have browsers and shells open, it’s all just there. This helps my workflow massively, allowing me to keep my train of thought going.

Writing plans and processes and sharing them

Quarto, which is already bilingual, is the tool I use to write meeting notes, lists and plans, all within a locally version-controlled Quarto book. The whole book is searchable, so it’s easy to find the notes I’m looking for, and Positron makes working with Quarto very easy. Positron comes with a bootstrapped Quarto extension and the CLI is bundled with Positron, so no extra setup is needed. I can create my planning documents, with nice mermaid flow diagrams and such, and I can publish them easily from Positron to share with my team. I’ve written a package that I can use within the IDE to automatically append notes to any of the .qmd pages of my notes book. I can even create diagrams and charts in the IDE, and save them into my notes. If the diagram is complex, I can append the code chunks and output to my book too, since that’s what Quarto is great at.

I love Positron’s feature that allows scrolling back through the iterations of a plot too, which makes rolling the code back to a preferred solution nice and simple.

Testing new functionality and UX

I need to understand how our products are experienced by our users, so it helps me to run our apps in development locally. Using Positron allows me to use a very similar workflow to my familiar RStudio one, including using {devtools} for documenting and running package checks and using devtools::load_all() to test out new functionality locally. In addition to this, Positron makes working with tests really simple (which is saying something coming from me!). The ‘testing’ icon in the activity pane opens a dedicated interface sidebar, which neatly displays your tests and their results (provided you are in a package folder). It lets you easily rerun failing tests, see their error messages, and rerun batches of tests or all tests at once. This is a really great addition to the IDE.

Juggling many projects

I flit between projects often. Double-clicking the R Project file allows you to start a new RStudio session with the project already loaded. But there is no direct equivalent of the .Rproj file for Positron.
This is a little jarring at first, but opening a folder to begin working in a project is a familiar workflow with VSCode.
I wanted a quick and easy way to switch between projects, and have found the Project Manager Extension useful for this. It creates a new multi-folder icon in the activity pane, which when clicked gives a neat overview of saved projects (folders), which I can tag easily to bundle together related projects. Lovely!

Helpers for doing good data science

I don’t want to lose my skills as a data scientist; I like to dabble and make useful tools for myself, and very occasionally I get my hands dirty writing code with the team. Positron is helping me write better code, quickly, which helps me look like a data scientist (I hope!). My favourite features so far are having my code formatted automatically when I save an R or Quarto file by the excellent Air formatter (shipped as standard with Positron), using code snippets to get the syntax of common functions right first time, and the cool multi-cursor for editing in multiple places at once!

Overall, Positron feels like a nice place to be. I’m finding it to be an IDE that helps with so many aspects of being a product owner, and that can only help us to keep building the right thing at the right time.

Introduction

Hi! This blog post acts as a follow up to my previous entry to the NHS-R Community website, regarding the use of random forest models to predict a patient’s length of stay. This time, the aim was to classify a patient as either “at risk” or “not at risk” of falling as an inpatient, utilising the XG Boost technology available within R. The classification depended on a variety of predictor variables, agreed with a senior digital nursing colleague working within the same acute trust as me. The intention behind this project was to see how accurately a patient could be classified into a fall risk category, using the agreed predictor variables. The goals and proposed methodology of this project were established after discussions with the previously mentioned senior digital nursing colleague, in which we set out to determine what the most appropriate way to approach this task would be regarding a clinical perspective, variable selection and potential clinical use cases. The accuracy of the eventually completed model was assessed through predictions on a testing data set, where the model was used to classify patients as either at risk of falling or not. This prediction was then compared with the actual fact of whether each specific patient did experience a fall during their inpatient spell or not. The testing data set for this accuracy assessment was a section of the primary data set used for this project, as the primary data set was split into both a training and testing section.

As mentioned within my previous predictive analytics post (linked above), this blog post is not intended to be a comprehensive guide on how to approach a machine learning task within R, best practice for utilising XG Boost or a complete overview of all of the relevant considerations necessary for such a project. This blog post is intended to act as an overview of how I approached this specific project, that hopefully potential readers might find interesting. The considerations and methods discussed within this blog post are specific to the context of this project only. If you are thinking about undertaking a similar machine learning project, you should seek the relevant guidance to do so.

Data Set Preparation and Variable Selection

For this project, the variables used were discussed with the previously mentioned senior digital nursing colleague prior to the development and testing of the model. The features were chosen as it was thought that they would act as ideal predictor variables for whether or not an inpatient may experience a fall. The final predictor variables used in the model were as follows, “Sex”, “Non-Elective Stay”, “Dementia Diagnosis”, “Current Delirium”, “Parkinson’s Diagnosis”, “Current Low Blood Pressure”, “Previous Fall Flag” and “Age Category”. A positive to using these particular variables was that they were all readily available in internal electronic patient record systems.

In order to transform and clean this data into an appropriate format, a SQL query was used to retrieve all of the relevant fields from the necessary electronic patient record systems and wrangle this into the data set that would eventually be used in the project. Next, this data was saved as a CSV file and used to train the model within the primary R script.

As the input for this specific model needed to be numeric, “one hot encoding” was once again used to create a numeric column for each value within the categorical variables. This encoding was performed within the R script itself.

Model Creation

This model was created in R using the following packages, “tidyverse”, “xgboost” and “caret”. The primary data set was initially imported into R as a CSV, this file is referred to in the example script below as “CSV File”. The data was then encoded using the function “dummyVars”, with any irrelevant columns then removed. For this project, the data was split into a training section containing 70% of the initial data and a testing section containing 30% of the initial data.

Following this, the optimal number of rounds and the maximum depth of the model were established. This was done through gradual adjustments to each of these values, with improvements and drops in performance and prediction quality noted. In the example script provided below, “x” would be replaced by the depth and “y” would be replaced by the number of rounds. Once the model was trained, the accuracy and recall was then assessed through a confusion matrix. As this was a heavily imbalanced data set, where a much larger proportion of patients did not experience a fall compared to those that did, the threshold for classification needed to be altered from the default value in order to receive meaningful and useful predictions. Within the example script, “t” would be replaced by the specific threshold value determined to be optimal for classification. For this project, the threshold was eventually decided through a process of gradual alterations, with improvements and drops within the accuracy and recall scores of the model noted.

The example script showing how this project was approached within R is shown below.

#LOAD LIBRARIES
library(tidyverse)
library(xgboost) 
library(caret) 

#SET SEED SO THAT RESULTS ARE REPRODUCIBLE
set.seed(200)

#IMPORT DATA
Results <- read.csv("CSV File", header=T, stringsAsFactors=T)

#CHECK INITIAL DATA
glimpse(Results)

#ENCODE DATA
dmy <- dummyVars(" ~ .", data = Results)

encoded_data <- data.frame(predict(dmy, newdata = Results))

encoded_data$Fall.Y <- as.factor(encoded_data$Fall.Y)

formatted_data <- subset(encoded_data, select = -c(Fall.N))

#CHECK FORMATTED DATA
glimpse(formatted_data)

#DATA SPLIT INTO TRAINING (70%) AND TESTING (30%)
parts = createDataPartition(formatted_data$Fall.Y, p = 0.7, list = F)
train = formatted_data[parts, ]
test = formatted_data[-parts, ]

#PREDICTOR AND RESPONSE - TRAINING
train_x = data.matrix(train[, -21])
train_y = data.matrix(train[,21])

#PREDICTOR AND RESPONSE - TESTING
test_x = data.matrix(test[, -21])
test_y = data.matrix(test[, 21])

#FINAL TRAINING AND TESTING
xgb_train = xgb.DMatrix(data = train_x, label = train_y)
xgb_test = xgb.DMatrix(data = test_x, label = test_y)

#SAMPLE MODEL
#X WOULD BE THE MAXIMUM DEPTH
#Y WOULD BE THE NUMBER OF ROUNDS
depth <- x
rounds <- y
final = xgboost(data = xgb_train, max.depth = depth, nrounds = rounds, verbose = 0, objective='binary:logistic')

#MAKE FINAL PREDICTIONS ON TEST DATA
pred_test = predict(final, xgb_test)

#ASSESS ACCURACY
#T WOULD BE THE IDEAL THRESHOLD FOR CLASSIFICATION, DETERMINED AFTER TESTING
threshold <- t
a = as.factor(test_y)
b = as.factor(if_else(pred_test >= threshold, 1, 0))

CONFUSION_MATRIX <- table(Test_Value = a, Prediction_Value = b)
CONFUSION_MATRIX

Performance and Challenges

As the data set behind this model was quite heavily imbalanced, one of the solutions used to attempt to overcome this was to manually alter the balance of the training section of the data set through “oversampling” and “undersampling”. While this did result in reasonably high accuracy scores, it is believed that an unintended consequence of this was that “overfitting” took place. This conclusion was reached as predictions in testing were not generally in line with what was expected, despite the reasonably high accuracy scores. Due to this, the original data set balance was used, with a lowered threshold for classification (as previously mentioned). One of the key variables believed to have contributed to the overfitting issue was age, when used in a continuous, numeric format. Performance was generally better when age was altered to present as a categorical field, for example, 0-18 rather than a specific numeric value. While the issue of overfitting seemed to be a lot less prevalent by the end of the project, as predictions were more consistent with what would be expected, it is important to note that this does not mean there was absolutely no overfitting present within the model still.

As previously mentioned, certain variables originally considered were eventually removed from the data set and not included within the final version of the model. This is because they were determined to generally not be good predictor variables within the context of this specific data set and model. They may have actually been hindering the overall performance of the model. The variables removed were “Current Dizziness”, “Current Elevated Heart Rate”, “Current Visual Impairment” and “Current Incontinence”. While these variables were determined to not be good predictors within this particular project, they could still potentially be useful within another setting and context for the same purpose of predicting fall risk.

For the variables utilised within the final model, a chart is shown below visualising the feature importance of all those still included. The plot was created using the package “ggplot2”. The R script for this plot is also shown below, the script presumes that the model has already been created, as the model “final” from the previous script shown is referenced.

#LOAD LIBRARIES
library(ggplot2)

#FEATURE IMPORTANCE
model_feature_importance <- xgb.importance(model = final)
model_feature_importance <- model_feature_importance %>% arrange(desc(Gain))

#FEATURE IMPORTANT PLOT - GGPLOT2
ggplot(model_feature_importance, aes(x = reorder(Feature, Gain), y = Gain)) +
geom_bar(stat = "identity", fill = "red") +
coord_flip() +
labs(title = "Feature Importance (Gain) Within Model", x = "Variable", y = "Feature Importance") +
theme_light()

Plot Of Feature Importance

The performance of the XG Boost model was compared with a Logistic Regression model and a Random Forest model, both also created in R using the same data set. Overall, the XG Boost model seemingly returned a better accuracy and gave higher quality predictions with this specific data set than either of the other classification methods.

As an inpatient fall could be considered to be rather awkward to predict, in that multiple patients that did not fall could theoretically be admitted with the exact same values as a patient that did fall, a goal of achieving an overall accuracy and recall score of 70% was set for this specific project. Precision, while very important for some projects, was not deemed to be a priority over recall and overall accuracy for this specific project. This is because the impact of a false positive (being a patient predicted to fall that did not actually fall) would be more acceptable in the context of this project than a false negative (being a patient that did fall but was predicted not to). The final accuracy score for this project was 69.39%, while the recall score was 67.83%.

Interactivity For Users

Similarly to the previously mentioned Random Forest prediction project, it was thought that users would need a way to simply interact with the model to input values and receive their predictions. For this, I created a shiny app that would allow users to utilise check boxes to input the various predictor values for a hypothetical patient. The app would then produce a fall risk classification based on these predictor values using the model. In theory, this app would be hosted and accessed internally within a trust, for relevant staff to use for predictions. Below, a screenshot is shown of an example of the final output of the app based on the predictor values entered. In this case, the model predicted that the patient would be a fall risk.

Screenshot Of App

Considerations and Notes

. If such a model were to ever be used for clinical purposes, it would require further validation to absolutely ensure that the performance was to a high standard and that predictions were meaningful. As previously mentioned, there may have still been overfitting present within the final version of this model, even if this was to a lesser extent than it would have otherwise been if the relevant corrections and amendments had not been made.

. While I opted to use an XG Boost model created specifically within R for this project, it should be noted that alternative classification methods and other tech stacks could have also been used to develop a similar model.

. When utilising patient data for such a model, there are obvious information governance considerations necessary. The data set used to create this model was limited to only variables that were utilised for predictions, no unnecessary information was extracted. Additionally, this data was wrangled, stored and analysed on the trust’s internal network only.

. My role within my organisation is not explicitly that of a “Data Scientist” or primarily a machine learning focused role, my current title is “Information Development Analyst”. While I have a keen interest in R, machine learning and the potential applications of this within the NHS, I am definitely not an authority in this area of healthcare analytics. The methods used for this undertaking are specific to the goals and context of this project only. If you are considering creating something similar within your own organisation, you should seek the relevant guidance to do so.

. Once the age variable had been altered to present in a categorical format, rather than as a continuous numeric value, it may have been more appropriate to utilise “ordinal encoding” rather than “one hot encoding” for this specific variable. However, a version of the model was created with this applied as an alternative and this did not appear to impact the performance of the model. Nevertheless, I plan to eventually create a second version of the model with this considered, along with more recent data included, as the time period for admissions within the data set used for this project was the 1st January 2021 - 31st December 2024.

. Throughout this blog post, I have continually referred to a senior digital nursing colleague who had valuable input into this project from a clinical perspective, particularly for considering potential clinical use cases and initial variable selection. Thanks Hannah for your contribution to this project!

Final Thoughts

Thank you for taking the time to read this post! I hope you have found it as interesting as I found undertaking the project itself.

There are certainly untapped applications for prediction models, similar to the one described in this post, to be created and implemented throughout the NHS and healthcare analytics more generally for a variety of clinical and non-clinical use cases. Some organisations may already have large amounts of resources dedicated to the development and implementation of internal prediction models, while others may not have started to explore the possibilities and potential benefits of this yet. Each organisation looking to implement predictive analytics would likely benefit in unique ways, depending on where attention and resources were focused. Wherever these models are implemented, it is obviously imperative that they are done so with care and extensively checked before they are allowed to influence any potential decisions within a healthcare organisation. As this technology has become more accessible through open source tech stacks (such as R and Python) and more digestible through the increased availability of online resources, I am personally excited to see any further developments, particularly within the NHS and wider healthcare space.

Introduction

Hi! This is my first blog post here and I’m excited to have the chance to share my thoughts with you on this topic, as it is something that has seemingly exploded in popularity over the last few years. For context, I currently work as an “Information Development Analyst” within an acute NHS trust. So naturally, I’m constantly exploring new ways of working within healthcare analytics and business intelligence, as well as aspects of data and technology that I might just think are interesting! This post specifically focuses on predictive analytics within R and my journey developing a prediction model within my organisation.

Machine learning for predictive analytics is becoming increasingly popular (and essential) throughout healthcare, particularly within the NHS. Machine learning models within healthcare can be successfully deployed for a variety of use cases. This area of healthcare analytics is constantly growing as new techniques become more prevalent and machine learning resources become more accessible to information professionals based within NHS organisations. While some of these solutions are deployed on a large scale and require the investment of an abundance of time and money, smaller scale models can often be developed in-house, taking advantage of the wide array of tools that R has on offer for machine learning. In this example, I will show how I developed a random forest model to predict whether or not a patient’s length of stay was going to be less than (<) or greater-than or equal-to (>=) 7 days. The data used to train such a model would be available for most data analysts within the NHS through their trust’s internal electronic patient record systems.

The code shown for this particular machine learning task is specific to the context and model discussed in this blog post. This is not a comprehensive guide on how to approach a machine learning task within R or a complete overview of all the relevant considerations necessary. While I hope that readers find this post interesting, anyone considering undertaking something similar should seek the relevant guidance to do so.

Data Set Preparation & Variable Selection

The variables used in the data set to train the model were selected as it was thought they would be useful as indicators for a patient’s length of stay. These included age, elective / non-elective admission, whether the patient was admitted from a nursing home or not, theatre records, the patient’s sepsis status and the presence of particular comorbidities (that is previous diagnosis of dementia, chronic obstructive pulmonary disease, heart failure and diabetes).

To allow the model to be trained on this data, all of the categorical variables had to be re-categorised using “one hot encoding”, where the values of each of these variables would then be represented in a separate column identified with a 1 or a 0. This alteration allows the input into the model to be numeric. As only categorical variables needed to be encoded, age did not need to be altered.

Preparation Of Model

The R script used to prepare and evaluate this model utilised the following packages: “stats”, “dplyr” and “randomForest”. Initially, the data set was loaded into R from a CSV file and the columns checked (for example formatting and column names). In this example, the CSV file is referred to as “DATASET”. Following this, the data set is split into a testing section and a training section. For this I opted for a split of 70% training and 30% testing. Then, the random forest model is built, specifying that the field “Length.Of.Stay” is the variable I am looking to predict and that I want to make this prediction based on all of the other variables available in the data set. Lastly, the model accuracy is evaluated through a confusion matrix. This model presents an accuracy of 85.11%, when evaluating the predictions made from the testing data set.

# load packages
library(stats)
library(dplyr)
library(randomForest)

# set seed
set.seed(10)

# dataset preparation
Results <- read.csv("DATASET", header = TRUE, stringsAsFactors = TRUE)

# check dataset
head(Results)

# split data into testing and training
index <- sample(2, nrow(Results), replace = TRUE, prob = c(0.7, 0.3))

# training
Training <- Results[index == 1, ]

# testing
Testing <- Results[index == 2, ]

# build model
MODEL <- randomForest(Length.Of.Stay ~ ., data = Training)

# evaluate model accuracy through a confusion matrix
LOS_Pred <- predict(MODEL, Testing)
Testing$LOS_Pred <- LOS_Pred

CONFUSION_MATRIX <- table(Testing$Length.Of.Stay, Testing$LOS_Pred)

ACCURACY <- sum(diag(CONFUSION_MATRIX) / sum(CONFUSION_MATRIX))
ACCURACY

Interactivity For Users

Once the model has been created and evaluated for usability, you may want to start thinking about potential methods to make the model accessible within your organisation. Ideally, a user would be able to input values for each variable into the model in as minimal clicks as possible. In this case, I experimented with a shiny application that would likely be the best way for users to input values into the model to receive a prediction.

However, it would not be ideal for the user to have to go through clinical notes and various systems to find the information they need for every variable. The solution arrived at for this issue was that a table would be created in SQL containing all of the relevant information for each variable, for any patients that have been admitted on the trust’s primary electronic patient record system. The relevant information for all of the variables would then be retrieved from various systems. This would be entirely managed within SQL. The data from SQL would be retrieved for use in R with the “odbc” package. In the example shown below, the table that contains a regularly updated feed of daily admissions is referred to as “[Database].[dbo].[Table]”.

# load package
library(odbc)

# connect to sql via odbc
myDSN <- "LOCAL_DSN_NAME"

# define query
con <- dbConnect(odbc::odbc(), dsn = myDSN)

# define query
MyQuery <- "SELECT * FROM [Database].[dbo].[Table]"

# run sql query
sql_result <- dbGetQuery(con, MyQuery)

Below, two examples are shown of test data inputted into the shiny app, one returning a prediction of “0-6 Days” and one returning a prediction of “7(+) Days”.

0-6 Days

7(+) Days

Considerations

Hosting for shiny applications is not currently widely available outside of public facing solutions, which would obviously not be appropriate for something such as this (that is information governance concerns).

Other machine learning model types available in R, such a “logistic regression” or “XGBoost” could have also been applied here for classification, as an alternative to random forest.

An NHS organisation may have developed similar machine learning models using alternative methods, such as python rather than R.

Final Thoughts

If you are working within business intelligence or data analytics within a healthcare space, you have likely encountered some form of machine learning tool, whether this is something you have developed yourself or made use of from a third-party application. It’s important to acknowledge that there are different scales of how far a machine learning model can be implemented within an organisation. How far an NHS trust integrates such technology may entirely depend on their IT infrastructure, budget and resources. However, the machine learning tools available in R certainly lower the barriers to entry if an organisation did wish to incorporate these methods into their analytics. Lastly, while the technology for projects such as this has certainly become more accessible, the time and consideration regarding variable selection, model testing and performance evaluation is still fundamental for a model to be accurate in its predictions and therefore useful from an operational perspective.

Thank you for taking the time to read this. Hopefully you found this interesting (and potentially even useful)!

Image from Stock Photos, Royalty Free Laptop with analytics Images | Depositphotos

GitHub actions

GitHub actions work, as the name suggests, on GitHub and are stored in the folder .github at the root (the main folder) of the Project. When a Pull Request is made to the main branch, which is good practice, you can trigger actions to flag up issues to resolve before merging.

Whilst it is possible to create GitHub actions using R, Python is a more usual language, particularly in places like the GitHub Marketplace which is where the PySpelling can be found.

The NHS-R Way was one of the first repositories I tried out this GitHub Action and I needed 3 files:

• .wordlist.txt (in the main folder)
• .spellcheck.yaml (in the main folder)
• and in the folder .github/workflows/ the file spellcheck.yml

All the files can be copied without changes but the .wordlist.txt requires specific spellings so you may wish to remove some or all of those used in NHS-R Community in case some of the words added are not suitable for your Project.

Running the GitHub Action to find spellings to save

Adding the three files will undoubtedly fail the GitHub Action when first pushed because it’s likely you will have a spelling that is not recognised by a universal dictionary. Also the checks are case sensitive so if you have any references which change from upper to lower case, these will both need to be listed, like NHS and nhs.

It is possible to expand the GitHub Action page on GitHub to view the log of previously run actions and you will need to do this when it fails. For the spelling GitHub action, each spelling “mistake” is shown between lines of dashes:

--------------------------------------------------------------------------------
NHSRpopulation
--------------------------------------------------------------------------------

I initially searched for the ----- lines using Ctrl+F through the browser but it turns out the search doesn’t extend to the log. I had missed that the log has its own search which appears at the top of the log webpage.

It’s then a manual task going to the wordlist.txt and adding the words and if there are true spelling mistakes it’s possible to search all files in RStudio by using the Ctrl + Shift + F rather than the Ctrl + F to locate the spelling mistake and correct it.

Forcing commits on GitHub

It’s possible to see on the Pull Request that there are multiple force-pushed commits (10 times!). Because there were so many spellings I did this in a few tries, adding a load, pushing the changes and re-running the action. I also was adding them in alphabetical order at first, until I realised I was never going to get through all of these before Christmas (and it’s February!).

On the one hand it’s ok to push all the changes to one commit as they are all related but on the other hand you will see this commit has 121 file changes to it as I had to tidy up a few files (see the later section about a rogue apostrophe). Whilst this was a decision that is ok to make: which is worse, more commits or more file changes, it is never recommended to force push to main or a branch that people are collaborating on because it changes history by changing the commit label. As I was working on a branch and within in Pull Request to main, I’ve reasonably assumed that it’s only me that will be affected by these changes.

The code to force a push is as follows:

• stage (add) all files (note the dot)
• amend the previous commit
• force the push

git add . 
git commit --amend --no-edit
git push -f

Updating a wordlist dictionary with multiple words

The NHS-R Community website had over 900 specific words to add (some were generated from weblinks) and when I (finally) looked for code to speed things up I realised I could just add all the spellings into the list as I found them, import into R to order and remove duplicates. Before importing and sorting just add Header or something similar to the top of the word list as this will become the column name and removed as part of the process.

library(here) # a package which is useful for referring to the project's path
library(dplyr)

file_path <- paste0(here::here(),"/.wordlist.txt")

# Check to see if the file exists (I misspelt this originally as .worldlist so 
# ironically couldn't find the file!)
file.exists(file_path)

# Import the .txt file into R as a dataframe
df <- readr::read_delim(file_path, delim = "\t")

# Order and remove duplicates
df2 <- df |> 
  dplyr::arrange(Header) |> 
  unique() 
  
# Write the text file to test.txt, copy over to .wordlist.txt if everything is ok
# or change the file name to .wordlist.txt and overwrite the original 
write.table(df2, "test.txt", 
            sep ="/",
            col.names = FALSE, 
            row.names = FALSE,
            quote = FALSE)

Replacing multiple and non-ascii characters

Copying over the files from WordPress brought across the ’ apostrophe which doesn’t appear to get recognised correctly even when the same is used in the .wordlist so I used the following code from a Gist to find and replace it to ' in multiple files. The only change I made to the Gist was to expand on the list.files base R function to change the pattern to find.qmd files and also show the full path because I was changing files in a subfolder (doing this means that the code to setwd() isn’t necessary):

library(here) # use instead of setwd() to show the file path rather than change it

path_to_subfolder <- paste0(here::here(), "/blog")

list.files(path_to_subfolder, pattern = ".qmd", full.names = TRUE)

Conclusion

You can go a very long time without needing to use GitHub Actions or even spell checks on your scripts but they can be really convenient and powerful bits of code that can speed up a possibly manual process.

What is Synthetic data?

The goal is to generate a data set which contains no real units, therefore safe for public release and retains the structure of the data.

In other words, one can say that synthetic data contains all the characteristics of original data minus the sensitive content.

Synthetic data is generally made to validate mathematical models. This data is used to compare the behaviour of the real data against the one generated by the model.

How we generate synthetic data?

The principle is to observe real-world statistic distributions from the original data and reproduce fake data by drawing simple numbers.

Consider a data set with variables. In a nutshell, synthesis follows these steps:

1. Take a simple random sample of and set as
2. Fit model and draw from
3. Fit model and draw from
4. And so on, until

Fitting statistical models to the original data and generating completely new records for public release. Joint distribution is approximated by a set of conditional distributions .

Synthetic data generation - National early warning score (NEWS) utilising real data

The data this is based on is the NEWS Score devised by the Royal College of Physicians.

Synthetic data can be generated from new data, utilising the above methodology, on the real observed data:

library(readr)
library(dplyr)
df <- suppressWarnings(read_csv("https://raw.githubusercontent.com/StatsGary/SyntheticNEWSData/main/observed_news_data.csv") %>%
  dplyr::select(everything(), -X1))

glimpse(df)

Rows: 1,000
Columns: 12
$ male  <dbl> 0, 1, 0, 1, 0, 0, 0, 0, 0, 0, 1, 0, 0, 0, 0, 1, 1, 0, 1, 0, 0, 1…
$ age   <dbl> 68, 94, 85, 44, 77, 58, 25, 69, 91, 70, 87, 93, 61, 75, 97, 80, …
$ NEWS  <dbl> 3, 1, 0, 0, 1, 1, 4, 0, 1, 1, 7, 2, 5, 1, 1, 3, 1, 5, 0, 2, 1, 2…
$ syst  <dbl> 150, 145, 169, 154, 122, 146, 65, 116, 162, 132, 110, 166, 123, …
$ dias  <dbl> 98, 67, 69, 106, 67, 106, 42, 56, 72, 96, 85, 90, 78, 80, 72, 81…
$ temp  <dbl> 36.8, 35.0, 36.2, 36.9, 36.4, 35.3, 35.6, 37.2, 35.5, 35.3, 37.0…
$ pulse <dbl> 78, 62, 54, 80, 62, 73, 72, 90, 60, 67, 95, 87, 93, 65, 89, 145,…
$ resp  <dbl> 26, 18, 18, 17, 20, 20, 12, 16, 16, 16, 24, 16, 26, 12, 16, 16, …
$ sat   <dbl> 96, 96, 96, 96, 95, 98, 99, 97, 99, 97, 87, 95, 96, 96, 98, 99, …
$ sup   <dbl> 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 1, 0, 0, 0, 0, 0, 0, 1, 0, 0, 0, 0…
$ alert <dbl> 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0…
$ died  <dbl> 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0…

This reads in the observed NEWS data from the GitHub repository. Now, we will utilise the synthpop package to create a synthetically generated dataset.

Generating synthetic NEWS dataset using synthpop package

As stated, now we will use the real observed data and generate a synthetic set, utilising the equations and process mapped out in the preceding sections:

library(synthpop)
syn_df <- syn(df, seed = 4321)

Warning: In your synthesis there are numeric variables with 5 or fewer levels: male, sup, alert, died.
Consider changing them to factors. You can do it using parameter 'minnumlevels'.

Synthesis
-----------
 male age NEWS syst dias temp pulse resp sat sup
 alert died

#### synthetic data
synthetic_news_data <- syn_df$syn
glimpse(synthetic_news_data)

Rows: 1,000
Columns: 12
$ male  <dbl> 1, 1, 0, 1, 1, 0, 0, 1, 1, 1, 0, 1, 0, 0, 1, 0, 1, 0, 0, 1, 0, 1…
$ age   <dbl> 56, 50, 74, 56, 52, 21, 37, 81, 67, 67, 56, 48, 76, 57, 43, 58, …
$ NEWS  <dbl> 1, 2, 6, 1, 0, 2, 1, 2, 5, 0, 1, 1, 0, 1, 1, 1, 1, 1, 3, 0, 1, 6…
$ syst  <dbl> 126, 115, 143, 122, 153, 164, 101, 125, 182, 160, 142, 122, 132,…
$ dias  <dbl> 84, 84, 86, 60, 89, 92, 57, 74, 103, 80, 113, 71, 59, 71, 89, 11…
$ temp  <dbl> 35.7, 36.8, 36.5, 36.3, 36.2, 35.5, 35.6, 36.6, 37.1, 36.2, 35.3…
$ pulse <dbl> 72, 94, 82, 94, 78, 97, 76, 71, 95, 86, 73, 62, 88, 70, 63, 100,…
$ resp  <dbl> 17, 14, 21, 12, 12, 20, 15, 17, 18, 18, 18, 16, 19, 16, 18, 18, …
$ sat   <dbl> 98, 97, 93, 98, 96, 99, 98, 97, 94, 98, 98, 100, 99, 97, 97, 96,…
$ sup   <dbl> 0, 0, 0, 0, 0, 0, 0, 0, 1, 0, 0, 0, 0, 0, 0, 0, 0, 0, 1, 0, 0, 1…
$ alert <dbl> 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0…
$ died  <dbl> 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 1, 0, 0, 0, 0, 0…

library(ggplot2)
# Create temperature tibbles to compare observed vs synthetically generated labels
obs <- tibble(label = "observed_data", value = df$temp)
synth <- tibble(label = "synthetic_data", value = synthetic_news_data$temp)

# Merge the frames together to get a comparison
merged <- obs %>%
  bind_rows(synth)

# Create the plot
plot <- merged %>%
  ggplot(aes(value, fill = label)) +
  geom_histogram(alpha = 0.9, position = "identity") +
  theme_minimal() +
  scale_fill_manual(values = c("#BCBDC1", "#2061AC")) +
  labs(
    title = "Observed vs Synthetically NEWS values",
    subtitle = "Based on NEWS Temperature score",
    x = "NEWS Temperature Score", y = "Score frequency"
  ) +
  theme(legend.position = "none")

print(plot)

CQC Directory

This vignette explains how to use the cqc_load dataset in R, and also details where it comes from and how it is generated.

The data is sourced from the Care Quality Commission and its archive is available on Google Drive.

The data contains care provider locations and ratings as published monthly in 2019.

The dataset contains data on locations and providers:

• location: location ID, name, ODS code, telephone number, web address, sector, inspection directorate, region, local authority, CCG, street address, parliamentary constituency, and coordinates.
• provider: provider ID, name, company/charity registration, telephone number, web address, sector, inspection directorate, region, local authority, street address, and parliamentary constituency. code for the organisation that this activity relates to
• pub_date: The date that particular data point was published

First let’s load some packages and the dataset and show the first 10 rows of data.

library(dplyr)
library(knitr)
library(tidyr)
library(ggplot2)
library(lubridate)
library(magrittr)

# Although the data isn't in NHSRdatasets it can be downloaded from the Pull Request using this code

load(url("https://github.com/MHWauben/NHSRdatasets/raw/274688bc727e800d5c40f06f86be38f866167818/data/cqc_directory.rda"))

# format for display
cqc_load %>%
  # show the first 10 rows
  head(10) %>%
  # format as a table
  kable()

We can calculate the total number of each type of rating at each datapoint like this:

rat_overtime <- cqc_load %>%
  group_by(pub_date, location_latest_overall_rating) %>%
  summarise(number = dplyr::n()) %>%
  filter(!is.na(location_latest_overall_rating)) %>%
  ungroup() %>%
  mutate(pub_date = as.Date(pub_date))

rat_overtime %>%
  pivot_wider(
    id_cols = location_latest_overall_rating,
    names_from = pub_date,
    values_from = number
  ) %>%
  kable()

We can now plot, for each month, the proportion of locations that received each rating:

ggplot(rat_overtime, aes(pub_date, number, fill = location_latest_overall_rating)) +
  geom_bar(stat = "identity", position = "fill") +
  theme_minimal() +
  labs(
    x = "Data publication date",
    y = "Proportion",
    fill = "CQC rating",
    title = "CQC ratings as published",
    caption = "Source: Care Quality Commission"
  )

Although the raw numbers show increases in each rating, this is primarily driven by more and more locations becoming available: proportionally, performance has remained fairly stable at a national level.

We can further break this down by region to better understand what is happening:

region_ratings_overtime <- cqc_load %>%
  group_by(pub_date, location_region, location_latest_overall_rating) %>%
  summarise(number = dplyr::n()) %>%
  filter(!is.na(location_latest_overall_rating) & !(location_region %in% c("Unspecified", "(pseudo) Wales"))) %>%
  ungroup() %>%
  mutate(pub_date = as.Date(pub_date))

ggplot(region_ratings_overtime, aes(pub_date, number, fill = location_latest_overall_rating)) +
  geom_bar(stat = "identity", position = "fill") +
  theme_minimal() +
  facet_wrap(~location_region) +
  labs(
    x = "Data publication date",
    y = "Proportion",
    fill = "CQC rating",
    title = "CQC ratings as published",
    caption = "Source: Care Quality Commission"
  )

More interesting patterns emerge now: some regions have growing proportions of ‘Good’ or ‘Outstanding’ locations, whereas others are seeing increases in locations requiring improvement.

How many new care homes are being opened?

With an ageing population, there is increasing demand for care home beds. Is supply keeping up?

carehome_openings <- cqc_load %>%
  mutate(location_hsca_start_date = as.Date(location_hsca_start_date)) %>%
  filter(care_home == "Y" & location_hsca_start_date >= "2014-01-01" &
    !(location_region %in% c("Unspecified", "(pseudo) Wales")) &
    pub_date == max(as.Date(pub_date))) %>%
  mutate(location_month = floor_date(location_hsca_start_date, unit = "month")) %>%
  group_by(location_month) %>%
  summarise(
    number = n(),
    beds = sum(as.integer(care_homes_beds))
  ) %>%
  mutate(
    location_year = as.factor(format(floor_date(location_month, unit = "year"), "%Y")),
    month = format(location_month, "%m")
  )

ggplot(carehome_openings, aes(x = month, y = number, colour = location_year, group = location_year)) +
  geom_line() +
  theme_minimal()

It is likely that the 2019 timeseries drops off due to a delay between provision starting and CQC reporting data. However, overall the number of new care homes opening is not increasing! Perhaps each care home is getting bigger; how many new beds are becoming available?

ggplot(carehome_openings, aes(x = month, y = beds, colour = location_year, group = location_year)) +
  geom_line() +
  theme_minimal()

This is a bit more encouraging: in 2016 and 2017, there was a good uptick in new care home beds. However, 2018 did not perform quite as well. Still, 2019 appears to be going in the right direction!

Setting things up

Ctrl + F7 in RStudio will open a new source column which you can use to gather together the information you want to share in your request for help.

library(dplyr)
library(datapasta)

You’ll often want to include a sample of your dataframe rather than the whole thing, particularly if it’s very large.

fresh_data <- NHSRdatasets::LOS_model |> dplyr::slice_sample(n = 20) # This produces a sample dataframe of 20 randomly selected rows. slice_sample(prop=0.2) will randomly select 20% of rows

Sharing your data

The base R function dput() produces the code to recreate your data sample.

fresh_data |> dput()

or another alternative is to use df_paste() from the datapasta package.

Editing the dataframe

You may need to edit the data before sharing it to anonymise it or remove confidential information. You could manually edit the output from dput() or df_paste.

# create a dataframe of organisation names and aliases
Organisation <- unique(NHSRdatasets::LOS_model$Organisation)
length(Organisation) # checks the length of the vector Organisation
alias <- letters[1:10] # if you want to automate this you could use letters[1:length(Organisation)]
df <- data.frame(Organisation, alias) # combines the 2 vectors into a dataframe

dplyr::left_join(NHSRdatasets::LOS_model, df) |>
  select(Age, alias, Death) |>
  slice_sample(n = 10) |>
  dput()

What should you include?

• libraries used

• your code and an explanation of what you’re trying to achieve

• the smallest dataset that still works

• error messages

• what solutions you’ve already tried

• check that the code you’re sharing works exactly like your original code with the issue. Sometimes you’ll realise for yourself what the solution is at this point!

• check that the code you’re sharing works exactly like your original code with the issue.

Don’t include:

• anything confidential

• any code that isn’t essential to the part you’re asking about

Where can you ask for help?

NHS-R Community Slack forum

The Posit forum, hosted by the company that makes and maintains RStudio

1. General thoughts about the Conference

The NHS-R/NHS.Pycom conference, is a great event to share on a yearly basis, our passion for advanced healthcare, promoting the use of our core R language for our healthcare analysis and also other exciting languages such as Python.

This is a small contribution as a blog post trying to summarize some reflections after attending for the first time last year NHS-R/NHS.pycom 2023 Online Conference. Right after the conference, I drafted some impressions in a LinkedIn blog post: https://www.linkedin.com/feed/update/urn:li:activity:7121902571715223552/ , but there were so much buzz and interesting ideas to develop months after the conference ended, that they could constitute an entire blog post.

I just want to stress that I have tried to convey some general ideas and thoughts about last year conference, but the share amount of code, projects diversity and different background of the speakers and organisations that took place in the 2023 Conference was enough to inspire me and try new coding projects for the rest of the year.

There was a great range of talks from specific insights on using R packages like {purr}, to a more technical sessions like the one about Modelling non-linear data with Generalized Additive Models (GAMs), using the {mgcv} package with Chris Mainey. https://nhsrcommunity.com/events/nhs-r-nhs-pycom-online-conference-workshop-2023-modelling-non-linear-data-with-generalized-additive-models-gams-using-the-mgcv-package/

What I most liked about the Conference was the mix of different speakers, ranging from Community developers, International Speakers and well known companies promoting the use of R and Rstudio such as Posit.

Some talks were Technical about specific models or packages, and others described problem solving situations in the NHS, where R has been used to create apps, like the talk where they used R to map EHR data to OMOP Common Data model on the 9th of October Online Conference or the Automatic reporting pack generation talk on the 11th of October.

On top of that, I really enjoyed other talks, where Python and PowerBI examples and projects were presented. It is a very inclusive event and seeing examples of different programming languages, broads our interest as analysts. There was always a good takeaway to try after the conference in R, Python or PowerBI.

I find really inspiring how the event manages to empower all analysts working in the NHS to add more languages to our toolbox, helping us in our daily work.

In this section below, I have listed the links to conference contents for each of the three main days 9, 10 and 11th of October 2023.

NHS- R/NHS.pycom Conference: Online Conference Talks – Monday 9th October 2023 Conference recording on YouTube:https://www.youtube.com/watch?v=X-fyKq1GXQI

NHS- R/NHS.pycom Conference: Online Conference Talks – Tuesday 10th October 2023 Conference recording on YouTube:https://www.youtube.com/watch?v=laKYVuElROs&t=1s

NHS- R/NHS.pycom Conference: Online Conference Talks – Wednesday 11th October 2023 Conference recording on YouTube:https://www.youtube.com/watch?v=3uSbLT7ISPc

Also I really appreciated that during and after the Conference, on the slack channel and on the NHS-R Conference website, all the GitHub repositories were made available with the talk slides and materials presented: https://github.com/chrismainey/GAMworkshop

2. Last year NHS-R/NHS.pycom 2023 conference was a great opportunity to listen live to analysts and Keynote speakers I have been reading recently. And to inspire existing ongoing projects

Earlier that year, I bought and read the New Book from Bruno Rodrigues “Building reproducible analytical pipelines with R”. https://www.amazon.com/dp/B0C87H6MGF/

That book has been extremely helpful for me to lean how to write more robust code, collaborate on GitHub with other projects, and also learn in more detail about functional programming. In fact, I used this knowledge to create the materials I used on the Lightning Talk I had the opportunity to present on the 10th of October. “Create a website using Quarto linking Rstudio with GitHub”: https://nhsrcommunity.com/events/nhs-r-nhs-pycom-online-conference-talks-2023-ticket-for-virtual-attendance-on-tuesday-10th-october-2023/

The presentation for that Lightning talk is available on GitHub: https://pablo-source.github.io/NHS_R_Pycom_2023.html#/title-slide. Alongside with the materials used to build it :https://github.com/Pablo-tester/presentations/tree/main/NHS_R_NHS_Pycom_Oct23

Overall, the topics covered during the NHS-R/NHS.pycom 2023 Conference allowed me to improve the quality of my R and Python code, and improved my collaboration with other analysts using Git and GitHub in a more efficient way.

This year I have tested these new skills on a new project using {target} library to build a small pipeline to build a univariate Time Series model using ARIMA and PROPHET models. I am sill expanding this initial pipeline project. https://github.com/Pablo-source/targets-test

3. Conference workshops

There were plenty of workshops available through the NHS-R/NHS.pycom Online Conference. These workshops were running in parallel to the main talk sessions, and running with a small groups of attendants. Its hands on nature was great to learn quickly joining efforts with other analysts. These workshop websites can be found in the NHS-R website past events section: https://nhsrcommunity.com/past-events/

I would have loved to be able to attend all the workshops, but unfortunately it was not possible, but I enjoyed the following five ones, with a great combination of advanced statistical analysis and visualization techniques.

NHS-R/NHS.pycom Online Conference Workshop 2023 – Modelling non-linear data with Generalized Additive Models (GAMs), using the {mgcv} package

https://nhsrcommunity.com/events/nhs-r-nhs-pycom-online-conference-workshop-2023-modelling-non-linear-data-with-generalized-additive-models-gams-using-the-mgcv-package/

NHS-R/NHS.pycom Online Conference Workshop 2023 – Create your own API with Python and FastAPI Workshop recording on YouTube:https://www.youtube.com/watch?v=_D4llf41KC8

NHS-R/NHS.pycom Online Conference Workshop 2023 – Introduction to Regression Modelling in R

NHS-R/NHS.pycom Online Conference Workshop 2023 – Data Visualisation with Seaborn Workshop recording on YouTube: https://www.youtube.com/watch?v=LZdbCOOdsPE

Also I do like that across all Conference workshops, RAP principles and Version control talks were present on several of the available workshops/

NHS-R/NHS.pycom Online Conference Workshop 2023 – Introduction to Version Control (Git/GitHub) Workshop recording on YouTube: https://www.youtube.com/watch?v=wOk7wDsHD8o

4. Final takeaway ideas from last year conference

• The NHS-R NHS-R/NHS.pycom Online Conference Talks 2023 is a source of inspiration for Analysts working with R and Python, from both Keynote, Plenary and Lightning Talks.

• Is also a great opportunity to meet analysts and developers from the NHS and also other Organisations and companies, allowing you to network and match specific projects with the people and teams developing it. Great to see the faces behind all these big projects.

• It is great to listen live international speakers from R and Posit and many other companies, explaining how they have designed the packages and tools sometimes we use in our day to day job. It is fantastic to see at the conference the developers presenting the most popular packages and tools we use in our day to day job.

• Thanks to the speakers and organisation making most of the talk materials available online, it is perfect to learn at our own pace in the months after the Conference has taken place.

• Also most of the tools used are R and Python, making open software and scripts used in the demos available on GitHub. That gives us plenty of materials to explore and learn from our own GitHub repos right after each conference day.

Setting up on GitHub

Publishing is through the Settings tab which is hidden unless you have rights to the repository.

There will be a Pages tab along the side which is where the settings can be changed https://docs.github.com/en/pages/getting-started-with-github-pages/creating-a-github-pages-site.

The NHS-R Community course repositories publish through the “deploy from a branch” setting with main and root on the branch but note that these have a redirect on the pages to the NHS-R web url so is called nhsrcommunity.com. Pages that are published through GitHub usually have github.io in the url name.

For Quarto files

If you are publishing a series of slides, as the format is often for NHS-R Community courses, if you add a blank file to the folder and call it _quarto.yml it acts like an engine to all the slides so you don’t have to repeat code. An example is https://github.com/nhs-r-community/intro-quarto/blob/main/_quarto.yml where the author is coded once here but appears on all the slides in this project folder. This isn’t needed for publishing but can make your code a bit less cluttered if you have many files to publish and means you only have to make changes in one place.

Create data

This was written originally in an Excel spreadsheet and used {datapasta} to copy into R as code to build the same data frame. {datapasta} can be access through RStudio as an Addin as well as code. Find out more about {datapasta} from the Introduction to R and R Studio course.

Recoding to NA

survey <- tibble::tribble(
  ~Survey.Response, ~Code,
       "Response1",   -9L,
       "Response2",    2L,
       "Response3",   10L,
       "Response4",    0L,
       "Response5",    5L,
       "Response6",   -9L,
        "Missing", NA
  )

Recode to NA

library(tidyverse)

survey |> 
  mutate(new_column = na_if(Code, -9))

# A tibble: 7 × 3
  Survey.Response  Code new_column
  <chr>           <int>      <int>
1 Response1          -9         NA
2 Response2           2          2
3 Response3          10         10
4 Response4           0          0
5 Response5           5          5
6 Response6          -9         NA
7 Missing            NA         NA

It’s also possible to use the numbers and case_when():

survey |> 
1  mutate(new_column = case_when(Code < 0 ~ NA,
2                                Code == 0 ~ 1000,
3                                .default = Code))

# A tibble: 7 × 3
  Survey.Response  Code new_column
  <chr>           <int>      <dbl>
1 Response1          -9         NA
2 Response2           2          2
3 Response3          10         10
4 Response4           0       1000
5 Response5           5          5
6 Response6          -9         NA
7 Missing            NA         NA

Or ifelse() where there are only two options:

survey |> 
  mutate(new_column = ifelse(Code < 0, NA, Code))

# A tibble: 7 × 3
  Survey.Response  Code new_column
  <chr>           <int>      <int>
1 Response1          -9         NA
2 Response2           2          2
3 Response3          10         10
4 Response4           0          0
5 Response5           5          5
6 Response6          -9         NA
7 Missing            NA         NA

Recode from NA

survey |> 
  mutate(new_column2 = replace_na(Code, 1000))

# A tibble: 7 × 3
  Survey.Response  Code new_column2
  <chr>           <int>       <int>
1 Response1          -9          -9
2 Response2           2           2
3 Response3          10          10
4 Response4           0           0
5 Response5           5           5
6 Response6          -9          -9
7 Missing            NA        1000

Create data

This was written originally in an Excel spreadsheet and used {datapasta} to copy into R as code to build the same data frame. {datapasta} can be access through RStudio as an Addin as well as code. Find out more about {datapasta} from the Introduction to R and R Studio course.

data <- tibble::tribble(
    ~Patient,          ~Codes,
  "PatientA", "A01, A02, A03",
  "PatientB", "B01; B02; B03",
  "PatientC", "C01; C03",
  "PatientD", "D01. D02. D03"
  )

Separate codes by position

Separate into columns in the order data appears

library(tidyverse)

data |> 
  tidyr::separate(Codes, c("col1", "col2", "col3"))

# A tibble: 4 × 4
  Patient  col1  col2  col3 
  <chr>    <chr> <chr> <chr>
1 PatientA A01   A02   A03  
2 PatientB B01   B02   B03  
3 PatientC C01   C03   <NA> 
4 PatientD D01   D02   D03  

https://tidyr.tidyverse.org/reference/separate.html

Add a pivot

To move wide data to longer:

data |> 
  tidyr::separate(Codes, c("col1", "col2", "col3")) |> 
  tidyr::pivot_longer(cols = c(starts_with("col")),
               names_to = "type")

# A tibble: 12 × 3
   Patient  type  value
   <chr>    <chr> <chr>
 1 PatientA col1  A01  
 2 PatientA col2  A02  
 3 PatientA col3  A03  
 4 PatientB col1  B01  
 5 PatientB col2  B02  
 6 PatientB col3  B03  
 7 PatientC col1  C01  
 8 PatientC col2  C03  
 9 PatientC col3  <NA> 
10 PatientD col1  D01  
11 PatientD col2  D02  
12 PatientD col3  D03  

The Community

Established in 2018, the NHS-R Community has rapidly evolved into a dynamic collective of professionals from diverse backgrounds. Our community encompasses members from public sector organizations, including Local Authorities and Civil Service, academia, and the voluntary sector. We are united by a shared passion for advancing healthcare through the transformative power of data. While our core language is R, we are equally enthusiastic about embracing a broad spectrum of data science tools, recognizing their integral role in shaping the future of healthcare analytics.

Steering the Course: The Committee’s Impact

As a committee member, my role involves active participation in shaping the community’s approach, focus, and overall strategy. We meet regularly to deliberate on initiatives, conferences, and the overarching direction for the community. The committee serves as a crucial forum for collective decision-making, ensuring that our initiatives align with the evolving needs of the community and contribute to positive change.

Committee Meetings: A Glimpse into Our World

Our meetings are a lively exchange of ideas, experiences, and visions for the future. Whether we’re brainstorming innovative projects, refining strategies, or planning impactful conferences, each committee member brings a unique perspective to the table. The collaborative spirit is palpable as we navigate the dynamic landscape of data science in healthcare.

Driving Positive Change

Being part of the committee means playing a pivotal role in fostering collaboration and steering the community toward meaningful outcomes. We celebrate diversity in thought and expertise, recognizing that it is the key to unlocking the full potential of data science in healthcare.

Contributions Welcome

One of the hallmarks of our community is the open invitation for contributions. Our GitHub repository: NHS-R Community hosts a wealth of resources, including packages and training materials, and we wholeheartedly welcome contributions from community members. It’s an empowering experience to witness the collective impact of our shared knowledge and skills.

Join the Conversation

If you’re passionate about data science, healthcare, and making a positive impact, the NHS-R Community is the place to be. Whether you’re an R enthusiast, a data science wizard, or a healthcare professional with an interest in analytics, there’s a place for you in our diverse and welcoming community.

As I continue my journey as a committee member, I’m excited about the endless possibilities that lie ahead. Together, we’re shaping the future of healthcare analytics, one R script at a time.

Stay tuned for more updates from the NHS-R Community, where data meets healthcare, and innovation knows no bounds. See you in the data-driven frontier!