• NHS-R Community Conference II

    My journey to work takes me about an hour and a half, and I catch a couple of buses with Wi-Fi which means I can browse Twitter and invariably end up with hundreds of tabs open as I flit between articles and blogs. Most mornings I find it hard to concentrate on reading through entire articles, especially the really long ones, so I leave the tab open on my computer, often for days, before reading them. Given my experience of reading blogs, why would anyone want to read through mine about the NHS-R Community conference?

    If I’d gone to the conference I’d probably skim that paragraph thinking ‘yes, I went, I know how good it was’.

    If I’d not gone to the conference I’d probably skim that paragraph because I might prefer not to know just how great a conference was when I’d missed it!

    Even though the conference was moved to a bigger location to accommodate more people and around 250 people attended, I have still spoken to people who didn’t get a ticket or missed submitting an abstract to speak. People who never made the conference are talking about an event that is only in its 2nd year. What is going on? What is it that has made the event so successful?

    Organising an event of any size takes a lot of work and that is often overlooked. There were the core people who did the real work – the arrangements – and quite frankly, they made it look easy, which itself is an indication of how hard they worked. But there were others who were part of a committee that chipped in with bits they could help with: setting up a specific email; reading through abstracts; suggesting things the organisers might consider, like how to ensure diversity of questioners (https://oxfamblogs.org/fp2p/how-to-stop-men-asking-all-the-questions-in-seminars-its-really-easy/).

    That organising committee was made up from a group who have shown a particular interest in R, and as such I found myself part of that group. Now although I have submitted a few blogs to NHS-R, I only really started using R a couple of years ago. Deep down I’m still a SQL analyst and my contributions to the conference were pretty minimal, but I feel encouraged to make those small contributions (even that last one about who gets to ask the first question in seminars) and each small involvement builds up to a bigger thing. This really is feeling like an equal and inclusive group and that’s where I think this success is coming from.

    It may have been by design or it may be a happy accident but there is a crucial clue in the name of this group that gives away its success – Community. This conference wasn’t managed top-down. There are some key people, of course, but they are as much of this Community as the people who contribute to the blogs, those that stood up on stage and showed their work, have those that will be learning to run the R Introduction training. This is our NHS-R Community.

    If you missed this year’s conference and want to go to the next one, get involved. The more people involved, the less work there is for everyone individually. Plus, given that tickets this year ran out in just 2 hours, you’ll be more likely to secure yourself a ticket.

    Speaking of which, provisional dates for the next conference are the 2nd and 3rd November 2020 (Birmingham). Now aren’t you glad you read this blog!

    Zoë Turner, Senior Information Analyst @AppliedInfoNott @Letxuga007

  • The NHS-R Conference 2019

    We really enjoyed our second ever NHS-R conference in Birmingham, which was attended by about 300 delegates. We tried to ensure that there was something for colleagues who are new to R as well as for those who are more experienced. The conference was inspiring, exciting, friendly and tiring and we obtained some fantastic feedback from attendees about how much they enjoyed the conference.

    “Let me take this opportunity to thank you for organising a brilliant conference. I learnt more in two days than I had in weeks on my own. Your enthusiasm is extremely catchy and inspirational.  Although I am relatively new in R, I am hooked on to it and wonder why I didn’t learn it before. I have already converted one person to R, my husband a consultant Psychiatrist in Edinburgh 🙂 …Once again thank you for your wonderful interactions during two days.”

    Dr Nighat Khan – University of Edinburgh and novice R user.

    “I think that the organisation was excellent, and the quality of the workshops and talks offered was extremely high…. I thoroughly enjoyed catching up with people that I already knew as well as meeting new friends. I have also come away with new skills to hone and new techniques to adopt and share in my work.”

    Caroline Kovacs – PhD Researcher, University of Portsmouth.

    “I just wanted to say I really enjoyed the event and (it was) probably the best conference I’ve attended.”

    Matthew Francis – Principal Public Health Intelligence Analyst and advanced R user.

    “I don’t think I’ve got the words to describe how fantastic the event was, fantastic just isn’t enough. I even presented at this conference after only learning R in the last couple of years. Truly, this was only possible because of the NHS-R community.”

    Zoe Turner– Senior Information Analyst at Nottinghamshire Healthcare NHS Foundation Trust

    We had some technical glitches on the day and some of the rooms were not ideal, so we want to thank our delegates for being so forgiving, patient and enthusiastic. Likewise, we want to thank our conference organisers, our helpers, our speakers, our funders – The Health Foundation – our sponsors (Mango Solution, Jumping Rivers, Healthcare Evaluation Data from University Hospitals Birmingham), our partners (AphA, The Strategy Unit, Improvement Academy, University of Bradford,  HDRUK) and all the staff at the Edgbaston Cricket Ground for helping make our conference a huge success.

    We have already started thinking about next year’s conference, and if you have any suggestions on how to make the next one better please let us know via twitter (@NHSrCommunity) or email (nhs.rcommunity@nhs.net).

    We also made some important announcements about NHS-R Community 2.0. This will be covered in a subsequent blog, but for now there is an announcement of free tickets to the EARL (Enterprise Applications of the R Language) conference 2020 which has been described as “The highlight of the R calendar in Europe” by  Andre Andrie de Vries of RStudio.

    Following a guest invitation for Mohammed A Mohmmed to talk about the NHS-R Community at the EARL conference in Sep 2019, Liz Mathews (Head of Community and Education at Mango Solutions) has generously offered members of the NHS-R Community 6 FREE tickets for EARL 2020 to be held on the 8th – 10th September at The Tower Hotel, St Katharine’s Way, London E1W 1LD. These tickets are worth £900 each and includes a day of hands-on-training workshops. So how might you win a free ticket?

    1. In 200 words maximum, tells us in an email to nhs.rcommunity@nhs.net “Why we should give you the free ticket and how will you ensure this will help the NHS-R Community?”
    2. The subject of the email should state “EARL 2020”.
    3. The last two lines of your email should state that:
      • you confirm that you will arrange your own travel and hotel expenses and that you will get approval from your employer where applicable.
      • In case you win a ticket but are unable to attend you will let us know ASAP so that we can allocate your ticket to someone else.
    4. For recorded talks, photos and highlights from the EARL conference 2019, which provides an excellent overview of what the event entails, please see https://earlconf.com/.
    5. You have until 31 Dec 2019 to submit your entries. Winners will be announced in Jan 2020.
    6. A small panel will judge the best entries and put then put them in a hat.
    7. We will randomly select 6 of the best entries and notify the selected person by email.
    8. If you do not claim your ticket within 3 working days of the notification email, we will exclude you from the process and randomly select someone else for the ticket.
    9. We will repeat the process until all tickets are allocated.
    10. In the event of tickets not being allocated, the NHS-R Team will allocate them as they see fit.

    The NHS-R Community Team

  • Moving on with the plan…And using R to do it! My personal experience…

    When Mohammed asked if I would be interested in doing a blog on how “we”, Information and Analytics in NHS Improvement, have been using R / R Studio I was a little apprehensive as I have never ‘blogged’ before, but I thought I would give it a try!

    So here goes —- my first ever blog!

    Many of us will remember Garry Fothergill’s engaging ‘lightning talk’ at the NHS-R Conference back in October last year ‘So what’s your plan’. Garry gave us a synopsis of how NHS Improvement had been using R Studio to support the annual process (torture to some) of activity planning for 2018/19. The original concept, ignited by Paul Stroner, arose from a central frustration of ‘flat line’ unrealistic activity plans of the past. I am sure some of us have been guilty of that, I know I have on occasion in the past!

    Since the original piece of R work, the team have been looking at further developments to the approach that Garry and Paul had set the wheels in motion on, with particular reference to how it could be used to support the 2019/20 planning round more formally. Back in mid-October it was agreed that both NHS Improvement and NHS England would use the univariate modelling approach that Paul and Garry had been championing.

    As part of this process the R code was reviewed and rewritten with some changes to methodologies in terms of validation processes (out of sample testing), applying adjustments for working and calendar days as well as models applied. The final R code was tested / Q&A’d by some of our esteemed NHS-R Community colleges and the overall approach was signed off by NHS Improvement’s Community of Practice for Statistics.

    As part of our offer to support CCGs and Acute Providers, a specific organisational level R code was developed (the code we used centrally – pulled in all 148 Acute providers for over 15 activity lines, based on day weighted and unweighted historical data, so you can imagine the number of models). The R code has been widely shared with organisations on request but also posted on Future NHS site and is also available on our newly created Github account.

    I personally can’t take credit for this R code, we are lucky in the Information and Analytics team that we have a colleague who has extensive R programming background …… if I could physically plug into his R brain I would! It is this expertise (and Chris Beeley’s workshop at the NHS-R event) that have opened my eyes to the art of the possible in using R Shiny Apps. This has led us down the path of designing and creating an R Shiny App, which allows organisations to replicate their forecasted figures that have been centrally provided within the activity planning submission template over the internet.  This tool can be used for any monthly data, all you need to do is make sure you have the upload data structured correctly, there is user help functionality included with the App – just click on the link below.

    https://nhsiadvancedanalytics.shinyapps.io/Forecasting_Support/

    I’m only at the start of my R journey, but I can already see the benefits of using it daily to support all aspects my reignited analytical life, so I’m excited about what the future holds! It’s a positive sign and a step in the right direction when these software programmes are being talked about by our NHS leaders, but what I am most enthused about is the will and the want to work collaboratively and share learning on all things R without judgement across organisations both internal and external to the NHS. So, I’m fully signed up to spreading the R message by being an active participant in any local R Working groups, presenting on R possibilities at different networking events whilst working as hard as I can on improving my own R skills. Watch this space, I may even take the leap and do some more blogs about my ‘R’ journey!

    This blog was written by Vicki Cruze, Principal Analyst in the Performance Analysis Team at NHS England and NHS Improvement.

  • From script-based development to function-based development and onwards to Package Based development: part 2

    At the NHS R Conference, I suggested to people that they should embrace the idea of package-based development rather than script-based work.

    In the first part of this tutorial, in the fictional NHS-R Community greeting room, our humble analyst was tasked with greeting people. Rather than writing a script and needing to repeat themselves all the time with different variations of greetings and senders, they wrote a rather nifty little function to do this:

    greet_person <- function(greeting = “Hello World”, sender = “the NHS-R Community!”) {
    
      if (!is.character(greeting) {
        stop(“greeting must be a string”)
      }
      if (!is.character(sender) {
        stop(“sender must be a string”)
      }
      if (length(sender) > 1) {
        warning(“greet_person isn’t very good at handling more than one sender. It is better to use just one sender at a time.”)
      }
      message(greeting, “ from “, sender)
    }

    As we know, R is awesome and many people took up R on the background of some excellent publicity and training work by the NHS-R community. Our poor greeting team got overwhelmed by work: it is decided that the team of greeters needs to expand. There will now be a team of three greeters. Every other bit of work output from our NHS-R community team will involve greeting someone before we present our other awesome analysis to them.

    This is going to be a nightmare! How can we scale our work to cope with multiple users, and multiple other pieces of work using our greeting function.

    If we rely upon the scripts, we have to trust that others will use the scripts appropriately and not edit or alter them (accidentally or on purpose). Furthermore, if someone wants to greet someone at the beginning of their piece of analysis, they’ll either have to copy the code and paste it somewhere, or link to our script containing the function – which in turn means they need to keep a common pathname for everything and hope no-one breaks the function. Nightmare!

    Fortunately, someone attended the last NHS-R conference and remembered that package-based development is a really handy way of managing to scale your R code in a sustainable way. So after a team meeting with copious caffeine, it is decided that greet_person needs to go into a new package, cunningly named NHSRGreetings. And here’s how we’re going to do it.

    In R Studio, go to File and then to New Project. Click on New Directory, and then click on R Package. I am using RStudio 1.2 Preview for this tutorial which is downloadable from the R website. I would recommend doing this as some of the package management has been greatly simplified and some frustrating steps removed.

     

     

     

     

     

     

     

     

     

     

    Click on ‘Open in new session’ (so we can see the original code), and set the Package name as NHSRGreetings. We could just pull our old source files into the package – but for this tutorial I’m going to do things the longer way so you also know how to create new functions within an existing package.

    Set the project directory to somewhere memorable.

    For now don’t worry about the git or packrat options – those are tutorials within themselves!

    You are greeted with a package more or less configured up for you. A single source file, ‘hello.R’ is set up for you within an ‘R’ directory within the package. It’s not as cool as our function of course, but it’s not bad! It comes with some very helpful commented text:

    # Hello, world!
    #
    # This is an example function named 'hello'
    # which prints 'Hello, world!'.
    #
    # You can learn more about package authoring with RStudio at:
    #
    #   http://r-pkgs.had.co.nz/
    #
    # Some useful keyboard shortcuts for package authoring:
    #
    #   Install Package:           'Cmd + Shift + B'
    #   Check Package:             'Cmd + Shift + E'
    #   Test Package:              'Cmd + Shift + T'

    So let’s check if the comments are right – hit Cmd + Shift + B on a Mac (on Windows and Linux you should see slightly different shortcuts). You can also access these options from the Build menu in the top right pane.

    You will see the package build. R will then be restarted, and you’ll see it immediately performs the command library(NHSRGreetings) performed, which loads our newly built package.

    If you type hello() at the command line, it will do as you may expect it to do!

    hello()
    [1] "Hello, world!"
    >

    So – time to customise our blank canvas and introduce our much more refined greeter.

    In the root of our project you will see a file called DESCRIPTION. This contains all the information we need to customise our R project. Let’s customise the Title, Author, Maintainer and Descriptions for the package.

    We can now create a new R file, and save it in the R subdirectory as greet_person.R. Copy over our greet_person function. We should be able to run install and our new function will be built in as part of the package.

    We can now get individual team members to open the package, run the build once on their machine, and the package will be installed onto their machine. When they want to use any of the functions, they simply use the command library(NHSRGreetings) and the package will be ready to go with all the functions available to them. When you change the package, the authors will have to rebuild the package just the once to get access to the new features.

    When writing packages it is useful to be very wary about namespaces. One of the nice things about R is that there are thousands of packages available. The downside is that it makes it very likely that two individuals can choose the same name for a function. This makes it doubly important to pick appropriate names for things within a package.

    For example, what if instead of the NHSRCommunity package someone wrote a CheeseLoversRCommunity package with a similarly names greet_person, but it did something totally different?

    In a script, you have full control over the order you load your packages, so R will happily let you call functions from packages and trust that you know what order you loaded things in.

    If you are a package author however, it’s assumed you may be installed on many machines, each with a potentially infinite set of combinations of different packages with names that may clash (or if they don’t already they might do in the future).

    So within the package, any function which doesn’t come from R itself needs to have clearly defined which package it has come from.

    Within DESCRIPTION you must define which package you use, and the minimum version. You do this with the Imports keyword. Attached is the Imports section of one of the SSNAP packages:

    Imports:
        methods (>= 3.4.0),
        lubridate (>= 1.7.4),
        tibble (>= 1.4.2),
        dplyr (>= 0.7.5),
        tibbletime (>= 0.1.1),
        glue (>= 1.2.0),
        purrr (>= 0.2.5),
        rlang (>= 0.2.0),
        readr (>= 1.1.1),
        stringr (>= 1.3.1),
        ssnapinterface (>= 0.0.1)

    Next within your functions, rather than just calling the functions use the package name next to the function. For example instead of calling mutate() from the dplyr package, refer to it as dplyr::mutate() which tells R you mean the mutate function from the dplyr package rather than potentially any other package. There are ways to declare functions you are using a lot within an individual file – but this method makes things pretty foolproof.

    Another tip is to avoid the magrittr pipe within package functions. Whilst magrittr makes analysis scripts nice and clean, firstly you still have the namespace issue to deal with (%>%

    Is actually a function, just one with a funny name – it is really called magrittr::%>%() !) Secondly the way magrittr works can make debugging difficult. You don’t tend to see that from a script. But if you’re writing code in a package, which calls a function in another package, which calls code in another package, which uses magrittr – you end up with a really horrid nest of debugging errors: it is better to specify each step with a single variable which is reused.

    When you’ve got your code in, the next important thing to do is check your package. Build simply makes sure your code works. Check makes sure that you follow a lot of ‘rules’ of package making – including making sure R can safely and clearly know where every R function has come from. Check also demands that all R functions are documented: something which is outside of the scope of this tutorial and is probably the subject for another blog post – a documented function means if you type ?greet_person that you should be able to see how to use the function appropriately. It can help you create your own website for your package using the pkgdown package.

    If your package both builds and checks completely and without errors or warnings, you might want to think about allowing the wider public to use your project. To do this, you should consider submitting your project to CRAN. This involves a fairly rigorous checking process but means anyone can download and use your package.

    If we can get enough people to develop, share their code and upload their packages to CRAN we can work together to improve the use of R across our community.

    Feedback and responses to @drewhill79.

    This blog was written by Dr. Andrew Hill, Clinical Lead for Stroke at St Helens and Knowsley Teaching Hospitals.

  • Local Public Health joins the paRty

    Having recently attended an R meetup in Birmingham, hearing of various user groups and hackathons that take place around certain technologies, I was getting a feeling that there was an increasing desire in the public health community to learn more about R and modern data science tools and techniques. I wondered whether there would be interest in a data science and R user group for the West Midlands public health intelligence community. I thought I’d raise the idea at the West Midlands Public Health Intelligence Group (WMPHIG) when I attended the quarterly meeting, but another attendee beat me to it and doing so confirmed there was some interest. I volunteered to arrange the first user group and Public Health England (PHE) kindly offered assistance.

    Between us we setup a date and venue for the first meeting at the PHE offices in Birmingham and I was pleased to hear from Nicola at PHE that “…Tickets are selling like hotcakes! “

    Not knowing exactly how the group would best work, we suggested a loose structure for the meeting with the following discussion points:

    • How this group should work
    • Assess current levels of knowledge/experience
    • R training requirements
    • R learning methods
    • Public health R use examples (including Fingertips R) & wider use examples
    • What could be done with R / What else do people want to do with R
    • Challenges and issues people have experienced/are experiencing
    • Possible joint projects that might benefit all members

    We ended up staying reasonably on topic, but there was plenty of useful and engaging discussion around the topics of data science and R. The was a nice mix of novice and more advanced R users (though no one admitted to being an expert 😉 ) in the group.  Many of those who were more advanced had fairly recently been novice users. Whilst the more advanced users were able to share their experiences of their learning journeys, others were able to contribute on how we might develop use of data science and R in Public Health Intelligence. I was also impressed with some of the examples of R use that were shared with the group by analysts who have only been using it for a relatively short time. A key point shared was though R may seem a bit daunting at first, its worth jumping in and getting your analytical hands dirty!

    A number of attendees had also managed to attend the NHS-R Community Conference and shared positive experiences of the day and the knowledge they’d picked up.

    Everyone appeared to agree that R and other modern data science tools/methods can offer a lot to public health intelligence.  There also appeared to be a desire to work together and help each other out on this learning journey. With that spirit in mind, we have agreed to share code and other useful information on K-Hub (https://khub.net/) and another meeting is going to be arranged for next quarter.

    Thanks to all that attended and contributed and to PHE for helping with the organisation.

    This blog was written by Andy Evans, Senior Officer at Birmingham City Council.

  • Thoughts on the NHS-R conference

    It’s been a few weeks since the first NHS-R conference was held in Birmingham.

    I co-presented a couple of workshops with Neil Pettinger on visualising patient flow, covering the following

    • importing from Excel (and connecting to SQL Server)
    • dplyr
    • ggplot2 & plotly
    • gifski for basic animation
    • automating reports with officer
    • gganimate demo
    • tidy evaluation via a custom plot function
    • alternative flow plots with ggalluvial
    • a simple Shiny app

    Code, data and templates for the workshop are available here.

    I hope those who attended found it useful.

    The event itself was a huge success. I’d have loved to have been able to see all the sessions that were taking place.

    There were a series of lightning talks – there are Trusts using R for machine learning and classification, and others using it for predicting admissions Chris Beeley presented on the use of Shiny, while Jacob Anhøj led a session on SPC using his qicharts2 package. It was a huge honour to meet Jacob, I’ve used his package almost since inception, and I know how much effort has gone into the rigorous analysis the package provides.

    I was also very pleased to meet Chris (Beeley), Gary Hutson, Ed Watkinson, Zoe (who masquerades on Twitter as Applied Information Nottingham) and Garry Fothergill face to face, and to see Val Perigo, Paul Stroner and Professor Mohammed Mohammed again. I also want to say thank you to Shahima who helped me revise my incredibly shoddy attempt at a bio, and for organising the event.

    From my point of view, the workshop was enjoyable to deliver. There were a couple of technical glitches ( I couldn’t share my laptop screen, so had to project it and then fly blind , which led to me spending more time facing the screen than the audience, which was not ideal), but even with that, we got through the material and it all worked within the alloted time.

    It was great to be in a room full of analysts passionate about R and the NHS. Neil mentioned ‘community’ in his blog post, and it is true. There was a greate vibe, as I’d expect to be honest. I’ve never been one for being part of a gang but anyone into R in the NHS is instinctively all right by me 🙂 I’m pretty sure there was enough brain power in that room to tackle any analytical challenge that could get thrown at the NHS. The challenge is in harnessing that power , promoting R as the incredible tool that it is, and enabling us to work collaboratively rather than in silos. If only there was an R package for that..

    This blog was written by John MacKintosh,  Data Manager at NHS Highland and was originally posted here.

  • NHS-R Community Conference: My experience of the day

    I went to the NHS-R Community Conference in Birmingham on Tuesday.

    It was great.

    Here are three observations about it.

    First, the old versus the new. Quite a few of the speakers alluded to the idea that R is sometimes seen in the NHS as this ‘new’ thing that is here to ‘replace’ the ‘old’ tools of Excel, SQL, SPSS etc. It’s an interesting dichotomy to ponder upon, (a) because it is of course infinitely more complex than that, and (b) because there are so many ways that it’s possible to cast R as the new ‘good guy’ and Excel etc. as the old ‘bad guy’. Having expressed caveats though, it was interesting to hear throughout the day how often people tended to explain what R was doing by reference to how Excel would do (or – more pertinently – fail to do) the same thing, only it would be more clunky in Excel.

    In fact, in the workshop on patient flow that I co-presented with John MacKintosh, we subconsciously had cast ourselves in these roles. I was the old bad guy who was over-reliant on Excel; John was the younger good guy who shows how you can do it better – and you can do more with it – in R. The visualizations we were showcasing were ones that I’d originally done in Excel and that John had improved considerably by using R.

    Second, and this next point follows on from the Excel versus R idea, I am intrigued by how ‘light on its feet’ R is. Can R respond to suggestions and edits from managers and clinicians ‘on the fly’? One reservation I’ve had about R as a tool for using at the clinical/managerial interface is that it looks too ‘data-y’, and therefore too forbidding, too exclusive and as a result it frightens the horses. Whereas one of Excel’s virtues is that it’s at least familiar to pretty much everyone, and therefore a bit less daunting as an interface, and you can make use of that familiarity by showing your workings in a way that has a chance of being understood.

    But in general I think I am persuaded by the swiftness and elegance of R as a data analysis tool. It might indeed look more forbidding than Excel but we can probably edit and re-draft our work ten times more quickly than we could in Excel, so in terms of rapid iterations (including iterations while we’re actually in the meeting), R wins. Again, I’ll quote an example from my workshop: John attempted some live editing of the code while we were presenting, and yes, it worked, so – yes – it was reassuring to know it can be done, even in in the middle of a presentation to an audience of 24 subject-matter experts.

    Third, and apologies of this observation seems a bit self-congratulatory, but it needs to be said. The mood of the conference was good. It felt congenial. There was a general ‘nice-ness’ vibe throughout the day. People were respectful, people were inclusive, it was easy to network.

    I remember thinking on the train as I made my way to the event that I might suffer from imposter syndrome when I got there. I have had very little exposure to R. I’ve made a start on the tutorials in DataCamp but I really haven’t got very far. And I am utterly indebted to my collaborator John MacKintosh when it comes to having my awareness raised as to the possibilities and potential of R. So I was a bit anxious that I might be sniffed at by the other delegates as someone who wasn’t a bona fide R geek, given that so many of the delegates had technical skills that were in a different class altogether.

    But I needn’t have worried. It turns out that’s not how the NHS-R community works. It’s inclusive, not exclusive. It’s a multi-disciplinary forum, not a talking shop for geeks. Which means that when the final plenary session for the day was trying to identify the main themes to emerge from the conference, it was collaboration that emerged for me as the key word. We do need to find ways of collaborating better. Collaboration that cuts across disciplines, and across organisations.

    But on the evidence of the mood and feel of Tuesday’s conference, collaboration should be easy, because this is a community of people who want to help one another.