Chris Witham

NHS Open Source Websites

Posted by: Chris Witham - Posted on:

Way back in 2010, in a dank basement in Sheffield, in the very early days of #SYWP (South Yorkshire WordPress), Kimb Jones, Jason Brewster and I wondered about the possibility of an Open Source WordPress theme that could be used by every NHS organisation. Fast forward a decade and I’m proud to lead a team who released an Open Source WordPress theme that takes the best of NHS Digital’s frontend library and makes it easy to use on any website. Hat tip to Tony Blacker who has done a lot of work to make this a reality and really fostered a community around it. It’s already has over 400 public installs from the WordPress repository and we’re aware of around 1000 installs used by GP practices already. It also allowed us to launch several large Covid response projects last year like www.people.nhs.uk to support our colleagues across the country. On a cold wet Saturday afternoon in January, I started thinking, what’s the real potential of Open Source websites in the NHS?

Note: this article is written to start a discussion and thinking. It is my hope that together, as a system, we can build better services for all our users. This article is not intended to point the finger or criticise anyone. I’ve worked in a hospital web team in the past and understand some of the challenges.

I’ve documented my research method below. It is by no means perfect. I’d welcome feedback and I make my data freely available through this Google Sheet so you can add to the research. I’ve focussed on provider Trust websites for this piece of research, based on this NHS provider directory from NHS England. It’s worth bearing in mind that in addition to these, there are Care Commissioning Groups (CCGs), Academic Health Science Networks (AHSNs), Arms Length Bodies (ALBs) and over 7000 GP practices who could make use of any potential solution.

The opportunity

  1. Let’s say 220 Trusts spend £50,000 – £100,000 updating their website every 3 – 5 years. Low bar, that’s £2.2m in potential savings we could achieve every year.
  2. NHS Digital have done incredible work on the NHS frontend library, building on the excellent work of the Government Digital Service (GDS). Whilst user research is really important to the specific journey your users are going to take, I can’t imagine most trusts realistically being able to undertake the level of research that has gone into the frontend library, nor do they need to as many of the journeys and interactions will be the same. We can use all this great work again and ensure every pound the taxpayer gives us is used 3, 4, 5 or more times.
  3. Using the NHS Design Principles, services will be more trustworthy, more inclusive and easier to use. Principle 9 – “Make things open. It makes things better.”
  4. A consistent, Open Source solution will offer opportunities to hundreds of SMEs to bid for and work on NHS and government projects. Bringing a boost to the economy and creating more diversity in thought and solution design.
  5. Many Trusts embed various versions of the Care Quality Commision’s (CQCs) widget, often in an old fashioned iFrame. An Open Source shared solution would make it easier to embed CQC and other third parties to build integrations.
  6. An Open API, consistent across all systems opens up potential for authoring content once and surfacing it in many places where it is needed. We’re implementing this with our local academies and our national website. Local events will be able to be promoted nationally but only have to be authored once by a regional team. Imagine the possibilities in a global pandemic, central messaging about the virus, lockdown or the vaccines automatically distributed and included on each Trust website instead of hundreds of people having to publish similar information everywhere. It would also make it easier for NHS England to display up to date information about each Trust without manually having to fetch and update this data.
  7. In my experience, many of us move around the NHS. Having consistent open solutions in every organisation would significantly reduce the training required when someone takes up a new role. If we align on a popular solution that is commonly used in other settings too, it would make recruitment easier and allow more people to seek employment in the NHS without having to retrain.
  8. Tony Yates recently wrote a great article on fixing interoperability. He demonstrated how easy it is to reuse common APIs and functionality when we build in an open way and are open to collaboration. Imagine the opportunity to roll out new functionality quickly if new services from the likes of NHS Digital were packaged up as a plugin to the common open solution and made available to all Trusts at the click of a button? How much better would our data validation and service be for patients and staff if every Trust could easily include the “Find your NHS number” service in their own website and processes?
  9. Mitigate vendor lock in and create a lively ecosystem that promotes innovation.
  10. Imagine central organisations like Health Education England or the NHS Leadership Academy being able to share their high quality staff support and development offers straight into the local websites that staff use everyday. Increasing engagement and promoting wellbeing.

Simply put, I think the main benefits of a consistent and open approach are:

  • Better for users – more accessibile, more trustworthy, more inclusive services that are easier to use.
  • Better for staff – less repetative manual work, a community of support, more training opportunities.
  • Better for the taxpayer – we pay for things once and get multiple usage. No paying for the same thing twice.
  • Better for organisations – more interoperability and more mutual support, essential as we look to develop Integrated Care Systems.

Leave a comment below with your thoughts on what you see as the biggest opportunities and benefits.

The state of NHS Provider websites

It’s worth noting that there are some Trusts already doing great things with their websites and digital communications. I am sure there are also organisations who have other priorities they are trying to address or fund. I think some organisations are probably the wrong shape or lack the right skill set to deliver high quality web presences. One thing I do know, is that web development is not the same as software development. Asking your IT team full of software developers who build clinical systems for you is unlikely to produce a great website, no matter how good they are at building critical systems for the trust. Web technologies evolve incredibly quickly and keeping up to date requires commitment to training and development.

Content Management Systems

Pie chart showing the range of content management systems used across NHS Provider websites.
Content Management Systems used across NHS Provider websites

It is encouraging to see that 56% of NHS Providers are already using an Open Source content management system. 51% of websites use a PHP based solution. WordPress currently powers around a third of NHS Provider websites. Therefore, 66 NHS Providers could implement the NHS Frontend library on their existing content management system with a few clicks in the theme installer, no technical knowledge required. Now admittedly, it won’t be quite that simple, hospitals tend to have large and complex information architectures, but NHS Digital have developed design patterns for such use cases which would be fairly straight forward to implement.

When developing a standard however, what choices might we make to drive behaviour change or contribute to other strategies? For example, NHS Digital chose Wagtail for the NHS.UK CMS. This looks incredibly capable and suits the kind of websites Trusts tend to require. It is also built using Python. Python is common in machine learning projects. If we’re going to make more use of big data going forwards, it could be prudent to train our staff in this programming language and embed this skillset in our organisations.

Brand guidelines

A pie chart showing the percentage of NHS Provider websites that follow NHS brand guidelines. No 56%, Yes 44%.
NHS Provider websites that follow NHS brand guidelines

I was hesitent to include this metric in my research. It is admittedly my opinion, highly subjective and open to interpretation. However, I hope it illustrates a point about trust and brand awareness. In my view, 123 websites don’t adhere to the NHS brand guidelines. The most obvious issue to spot is the use of incorrect shades of NHS Blue but there are also many websites that seem to have designed to be trendy rather than trustworthy.

In a world where there are many scammers trying to imitate NHS websites, it is more important than ever that those of us running legitimate services look like the real deal and can be easily recognised and trusted by the public.

Rhidian Bramley demonstrates that scammers are often better at implementing NHS brand identity than actual NHS organisations:

Security

A pie chart showing the percentage of NHS provider websites with valid SSL certificates. No 6%, Yes 94%.
NHS Provider websites that have a valid SSL certificate

Continuing the theme of trustworthyness, 13 NHS Provider websites had issues with their SSL certificate. This just needs to work and shouldn’t be an issue anywhere.

Accessibility

Hopefully we can all agree that making our services accessible and inclusive should be a prioritiy for all of us?

45 websites didn’t have any accessibility issues on their home page (check research method for details). Of the remaining 174 websites that I checked, there were an average of 10 accessibility issues per site with one site having 109 accessibility issues on their website alone.

32 websites had no colour contrast issues on their home page. The remaining 154 websites had an average of 18 contrast issues on their homepage.

Whilst accessibility needs to be a careful blend of user interface design and content design, contrast ratio issues should be easily solved by implementing the NHS frontend library. Being partially colour blind, I’m particularly aware of the issues caused by poor contrast ratios. We shouldn’t let flashy designs come before user needs.

A pie chart showing the percentage of NHS Provider websites that have valid HTML. Yes 9%, No 91%.
NHS Provider websites that have valid HTML on their homepage

Whilst not directly an indicator of accessibility, valid HTML is a good litmus test for a number of things including accessibility and performance. Only 20 NHS Provider websites had valid HTML on their homepage. You’re unlikely to win an award for the neatest HTML but it is important that we ensure our services meet the WCAG 2.1 level AA standard.

WordPress can check content before publishing to ensure basic things like alt text is set on all images. Consistently implementing the NHS frontend library will also signficantly improve the standards compliance of our services. In such, technology can support and educate content authors in best practice with helpful reminders embedded into their workflows.

Cookies

Pie chart showing the percentage of NHS Provider websites that have a clear cookie policy. No 22%, Yes 78%.
NHS Provider Websites that have a clear policy on using cookies.

All bar 5 of the NHS Provider websites use Google Analytics and there is broad use of other systems that rely on cookies. Therefore, you’d expect a near perfect track record for adherence to cookie regulations. However, 49 websites did not have a clear link about cookies or ask for cookie consent on their homepage. Handling cookies in a good, sensible way that is easy for users to understand and isn’t really irritating, is quite hard. NHS Digital developed a really clear pattern for cookie consent for the NHS.UK website. Using a standardised Open Source solution would allow this to be rolled out everywhere with ease and save technical teams having to solve the same problem multiple ways.

Responsive design

A pie chart showing the percentage of NHS Provider websites that have a mobile responsive design. Yes 91%, No 9%.
NHS Provider websites that have a mobile responsive design

It was good to see that the majority of NHS provider websites utilise a responsive design.

Every month, Matt Hobbs shares details about the types of devices that people are using to access GOV.UK. High percentages of users are on a mobile device. It is essential that our services are easy to use for the growing number of people who use a mobile device as their primary device or only own a mobile device. We cannot assume that users have the option of using a desktop browser, nor should we force them. The NHS frontend library is designed to work on any size screen and has been thoroughly tested on a wide range of devices and systems.

Content

A word cloud showing the popular main menu items from NHS Provider websites.
NHS Provider website main menu links

Whilst there are obvious variations to website content, type of Trust being a primary differentiator, there is considerable commonality in NHS Trust websites. Whilst design needs to centre around users and their needs, I think the user personas for a Trust website are going to be fairly standard and the user stories too. There obviously needs to be consideration made for acute, ambulance, community and mental health specialisms within content, but often there is a high overlap in people when it comes to service users.

  • Patients – details about appointments, services, who will be caring for them
  • Visitors and carers – how to get there, where to park, visiting hours, contact methods, facilities
  • Staff – research, news, directories, governance
  • Third parties e.g. GPs – referrals, media enquiries, contact details
  • Prospective staff – what the organisation is like, job adverts

Whilst we couldn’t have exactly the same content for every website, what would the opportunity be to create Open Source patient information? It seems a lot of hospitals still design and publish all their patient information as PDF leaflets. Presumably because they are printed and made available in hospital buildings and then quickly uploaded to the website without a second thought. Web first, HTML based patient information could be more accessibile to a lot of people. Imagine if we added QR codes above patient information points in buildings that opened the right page on the NHS.UK or Trust website? (I think this was actually worked on at a recent NHS Hackday). A simple progressive web app (functionality that alread exists in our NHS WordPress theme) could make this information available offline on users devices. Users could favourite the information they need regularly instead of having to keep track of paper leaflets that get tatty over time. The savings in printing costs could pay for other ways of making data available, whether audio, braille or different forms of digital signage?

An aside on audio – there is a great WordPress plugin for AWS Polly that makes it incredibly easy to make your website content available as audio, quickly and for next to no cost. Imagine if we could roll this out to all Trust websites at the click of a button and do away with the current mix of different speak out loud options and their fees? I used the plugin to create an audio version of the People Plan in just a few minutes. It also does content translation and audio in different languages too.

Risks

  • It’s reasonably easy to make resources like the frontend library and the WordPress theme publicaly available and licence under something like the GPL licence but it’s much harder to ensure people continue in the same spirit and encourage them to release their own developments for the benefit of the whole system. I’m already aware of one Trust that have taken resources, paid for development and not released the results as they consider it to be their IP and to have a commercial advantage.
  • Some will argue that Open Source NHS assets make scam and phishing sites easier to setup. Whilst there is some truth to this, it is so easy to save a HTML version of any website on the internet, I don’t think it really creates an opportunity that isn’t there already. In fact, GDS have published guidance on security considerations for coding in the Open. It can actually be a positive thing as more people can check and improve your code.

Conclusion Thoughts

  • There is already good use of Open Source technologies across NHS Provider websites. There is clearly an opportunity here. What are the barriers that put others off? What are the attractions elsewhere?
  • We could do more to improve the trustworthiness of NHS websites (where they don’t currently use the NHS frontend library). The NHS has a strong brand that is recognised around the world. We should capitalise on this. Standardising on the use of brand could remove a lot of expensive, repetitive design costs. Ensuring NHS websites use an nhs.uk domain name is also key. 2 provider websites do not currently use .nhs.uk.
  • Accessibility and usability are big areas where improvement could be made – this requires lots of research, testing and expertise. It seems impracticle for this to be undertaken by every Trust independently.
  • While some organisations clearly prioritise digital communication, others have not invested in their web presence for nearly a decade – what is the opportunity to support these organisations?
  • I believe Open Source, working in the open and fostering communities of practice can be very beneficial to the NHS, not just in websites but throughout digital transformation. However, websites seem like a fairly consistent, reasonable standard product that could be widely adopted in a reasonable timeframe. There are less dependencies and hard to remove legacy systems than say a Patient Administration System (PAS). It seems like a good test bed to introduce organisations and boards to Open Source and new ways of working. Issues could be ironed out and lessons learned before more abitious Open Source health and care projects were attempted.
  • What if we could have an Open Standard for patient information and a central library of resources that could be automatically pulled onto Trust websites and augmented with local specifics?
  • How might we incentivise organisations to get on board with an Open Source agenda? Could we centrally fund some early adopters to start the ball rolling and compensate for the additional benefits that followers will reap?

I really hope we can build a conversation and some collaboration in this space.

We worked with Ian Roddis, Dean Vipond, Adam Chrimes and team when they were starting out on the NHS Frontend Library journey. We shared our experience of developing an NHS branded website theme and made an introduction to Harry Roberts which brought a lot of architecture best practice and performance to the mix. It’s been great to continue collaborating together and bring the Frontend Library back into our Open Source NHS WordPress theme.

Developing the Open Source Community around those products has led to receiving support and contributions from some of the best Development Agencies in the UK (free of charge) and individuals on three different continents. Companies have told us how they’re willing to contribute back to the project as it has saved them so much time in servicing their NHS clients. All while improving the user experience and implementing best practice. To date, I think the Open Source WordPress theme has saved the taxpayer around £5m and we’ve only just scratched the surface of what’s possible.

Share your thoughts in the comments below and let’s start to work together to deliver on the NHS Service Standard.

Further reading

You may also be interested in the following articles on this subject:

Research method

I worked from the NHS England NHS Provider Directory. Whilst there are many NHS websites that this doesn’t cover, it seemed like a good cross section of websites that people right across England engage with regularly and it was a manageable size to research in my own spare time.

Process

  • Search for the Trust name in DuckDuckGo (other search engines are available).
  • Visit the Trust website and record the URL.
  • Record the date I visited the site.
  • Quick visual inspection of the homepage to see if I thought it adhered to NHS Brand (rather unscientific)
  • Check the SSL certificate is valid
  • Test the website with the WAVE website accessibility evaluation tool and record accessibility and contrast errors.
  • Test for valid HTML markup using the W3C HTML Validator Firefox Plugin.
  • Visual check for a cookie consent banner or in page search for the word “cookie”. Some sites seem to include this information under a “Privacy” link or heading but that was recorded as a fail.
  • Check the website through the Built With service and record the CMS used and whether the site uses Google Analytics. If a CMS couldn’t be determined, a quick manual inspection to see if the CMS could be determined. Chreking ‘/admin’ or ‘/login’ usually reveal what is powering a site.
  • Screen capture any menus in the header of the homepage using Text Sniper and paste these values into a Google Sheet so content analysis could be completed.

I repeated this process for all 219 organisations listed on the NHS Provider Directory. 2gether Trust was left out because they have merged and become Gloucestershire Health and Care NHS Foundation Trust who are listed separately on the directory.

All the data is available in this open Google Sheet. Please feel free to use the data for your own research, but do please share any further work in the spirit of collaboration and working in the open.

9 replies on “NHS Open Source Websites”

  • I love this approach. At some point, I feel the NHS will see the value of a dedicated inhouse web agency. NHSD and NHSx both exist and do great things, but either a team within one of those or a standalone team that just focused on the public facing web estate of the NHS. We have SO MANY websites, and there is a huge amount of variance in approach, design and technologies used. And a huge amount of money being spent where that same money could have much greater bargaining power if used collectively. We have economies of scale built in to the NHS by default. We really should be leveraging it. Having our own team of people who both understand the web and also understand the NHS and the way we work would be a huge benefit. Just my opinion fwiw.

    Tony Blacker
  • We work with Primary Care exclusively and support GP practices in building and producing websites. Practices teams are not the right size to develop the level of knowledge needed to get websites right – it is a profession in its own right – with a11y, GDPR, Standards, changes in browser support etc.

    We’ve used the Nightingale theme as the base of our solution – doing so lets us forget so much about design and focus on how to help practices easily publish content, building a content library, and integrating into the other tools they use and signpost patients too. We’ve been doing this in the open, and publish our plugins and blocks back openly. We want to enable anyone to pick up the information a practice has published in an open, scalable way.

    Lisa Drake has some good thoughts around this also – https://lisad.blog/2019/02/23/gp-websites-just-what-is-their-primary-purpose/

  • Amazing work! And these are just the main Trust sites.

    I inventoried an NHS Trust in 2020. They’d launched 6 new websites (design and build) in 6 months. To my knowledge, each were separate/siloed projects. Horrendous waste time, opportunity and other peoples money.

  • This is good work. Really good to see use of a range of factors. There is this resource for standards: https://digital.nhs.uk/about-nhs-digital/standards-for-web-products

    For security, I’d be surprised if that high a proportion of sites had GOOD SSL certificates. It seems likely that a large portion might support obsolete standards (SSL3, TLS 1.0 or TLS 1.1) or have weak standards. https://www.ssllabs.com/ssltest/ gives a good indicator.

    Also for security, it’s also important to check for security headers (try https://securityheaders.com/)

    I think this all illustrates the challenge of having hundreds of websites.

    In many cases, the first challenge should be whether these websites should exist at all. Does a GP surgery having a website really make sense in the user journey? Or would it be better to have it all mediated through NHS.UK.

    Owain Davies
    • Some great thought Owain. And definitely more that could be done around checking sites. Rob Dyke said he’s going to try and write a spider to automatically perform the tests and update the list. We could think about what needs to be included and where we can align to standards like the NHS Digital ones. Could be used to baseline and track how things improve over time.

  • Great article Chris, I really enjoyed reading through it. Your article resinates with our current thinking on providing digital services for GP practices. The variation in standard of current GP websites varies greatly and can often be confusing for patients to navigate or trust. We are working to address this with general practice in partnership with them.

    • Hi Dillon, I wonder if GPs are a good place to do something really transformational for the general public? I’ve been trying to find an old quote I heard at a conference. Something like “Hospitals are really really important to almost no one”. Clearly there is so much good work that hospitals do, but the point was basically that in any given year, the percentage of the whole population who actually required acute care is only around 12%, where as the percentage of the public interacting with primary care is much higher. And most GP practice websites are fairly terrible. Not sure what the possible overlaps with the NHS App are, do I still need a GP website if all my booking and prescriptions are handled in the app? I think my GP practice requires about 3 clicks to get to the phone number! And then it isn’t clickable so I have to write it down and type it back in to my smartphone.

      • Hi Chris

        thanks for the feedback. We agree that the current state of GP websites as a whole is terrible. We want to move practices away from ‘digital notice boards’ where information is outdated and yes phone numbers difficult to find. Having previously worked for an online consulting provider I know they encourage Practices to ‘hide’ the phone number to get patients to default to using OLC platform.
        We hope our work erradicates the current variation in quality and addresses the real problems that patients have with digital services. Many pages in GP websites are for information only then drive the actvity offline.

        We are just onboarding some practices at the moment and will keep our work open and transparent to share findings etc.

        Dillon Sykes
  • Chris, lets pick this up in a joint conversation. I met with NHSX CTO Dave Turner a few weeks back to discuss their GitHub organisation and much of what you have said unsurprisingly matches his thinking. How can we continue to write, publish and encourage the use of standards and common code. For NHS E&I, we now have an IT Standards library on GitHub for example – not that much in it as yet but I’m encouraging people to contribute. We also have an NHS organisation on GitHub which would be ideal for sharing and promoting standards and standardised code & Dave is certainly thinking along those lines.

    Open Source is just a part of this thinking though. “Working in the open” is a phrase I’ve used a fair bit to describe the overall process and mindset. It can be applied to documentation, standards, and not just code. Look at the MoJ GitHub for examples of open documentation.

Leave a Comment

Your email address will not be published. Required fields are marked *