A Shared Codebase for NHS Web Applications
Big functionality without a big burden to the taxpayer
Omni have been working with the South, Central and West Commissioning Support Unit (SCWCSU), and the Bristol, North Somerset and South Gloucestershire Clinical Commissioning Groups (BNSSG CCG's) since early 2014 to one aim: producing websites, consultation apps and communication tools to the same level as the fantastic gov.uk site.
From the start of the relationship, we respected the fact that the NHS holds a special place in British society - but a quick glance at many NHS systems, software and applications would suggest that the current options available to it were not meeting its unique needs. We decided that a new approach would be needed - and Omni, BNSSG and the SCWCSU decided to build a suite of tools where the underlying codebase was shared - no binding contracts or legal tie-ins. As soon as any site was deployed, the NHS organisation owned that instance, no questions asked.
Managing the Collaborative Approach to Development
When all partners of a shared codebase own their site, it would be tempting to allow their paths to diverge, and let different feature requests dictate the flow of development on different sites.
Omni made sure that the core codebase was maintained as its own clearly defined entity, and that all feature requests are either included in the core development workstream, or were created as modules which can be installed on a per-site basis. Over time, this has resulted in significant cost saving for each site, as security updates and new core features could be installed on each instance without any specific development costs incurred in making the patch relevant for multiple codebases.
To achieve this, we first had to establish a principle whereby if one partner paid for the development of a piece of functionality, and Omni built that functionality into its own app, the resultant app would be available to all other members of the partnership simply for the fees incurred in deployment, configuration and training. Where possible, we looked to combine feature requests from multiple partners to further reduce and share the cost of development.
Design, UX and Accessibility
One of the challenges with this relationship was meeting the NHS' branding requirements, ensuring also that design considerations for one system did not affect the others, without at any stage compromising on accessibility.
The design was forward-thinking at the time, and fortunately this has lead to the sites largely still conforming to NHS guidelines, despite them having recently been updated. The default design for core NHS is clean and clear - we nicknamed it 'clinical', and it allows for per-site customisations and overrides i.e. colour changes, alterantive logos and social feeds etc. Crucially, it puts content and patients' needs first, and is quick to load and easy to navigate.
The user experience has always been focussed towards simplicity and ease of use. A search box is featured prominently, and an overall information architecture is enforced to ensure that the user is able to find what they need quickly - regardless of whether they are a conscious visitor to one of the partner sites, or have been directed to one from a search engine. Given the NHS' target user groups' needs, this is critical to real human wellbeing.
Accessibility, of course, has been a continuous process of development, content writing and editing, and evaluation. The site was built leaning towards gov.uk's suggestion that real users were more important than a simple check-box approach to accessibility, and as such during the build phase Omni tested prototypes on members of the public with special requirements.
Since launch, the site has been through two separate re-audits, covering both content as well as code, first with a blind accessibility consultant, and the second through an accessibility audit professional. As we would expect, both audits produced valuable in-site into how we could better police content, and highlighted new techniques and considerations which we could release into the shared codebase.
"The process was collaboratively challenging, engaging and rewarding and the end result is user friendly for both the CCG and the public, distinctive in its appearance, and above all flexible to potential future needs."
NHS CCG Regional Project Lead
The core codebase and its associated applications have grown considerably over the last few years, and is now used in various configurations across six NHS organisations and one independent charity - a total of 12 servers and something like 24 production, staging and testing sites.
The applications currently available are:
- consultation tool for public healthcare-related questionnaires
- research metadata modelling system
- configurable library for patient facing documentation, GP referral information, and care pathway data
- local health service waiting times comparison
- NHS Choices API fetching service to allow administrators to display to end users location-specific information alongside national NHS-provided data
- Intranet, networking and private data storage tools
- Easy build and deploy of simplified microsites that utilise the same codebase e.g. On Your Mind
Going forward we are looking to partner with other forward-thinking NHS and healthcare organisations who recognise the value of patient-centred and interoperable services.