NHSi's Workforce Plans : briefing notes

Ed Schroeder - 06 September 2019

This is the first article concerning NHS England/Improvement's mandated standards, their proposed approach to interoperability for NHS workforce deployment systems, and the conformity of our services to those standards. The second article concerns our approach to interoperability and APIs and how that approach reconciles with NHS England/Improvement's intentions for the NHS workforce deployment systems market.

Index

Index to this document:

Introduction

In November 2018 NHS Improvement (known as NHSi) announced plans to mandate standards for NHS workforce deployment systems focusing on electronic rostering, job planning, junior doctor and related services, such as staff agency services. This announcement follows the publication of the Department of Health & Social Care's Policy for technology in healthcare (October 2018). This policy includes the following statements:

"We need to focus on getting the basics right: the digital architecture of the health and care system – the building blocks. Open standards, secure identity and interoperability are critical to the safe and successful use of technology, ensuring that systems talk to each other and that the right data gets to the right place at the right time...
We need modular IT systems, where any module can be easily switched out, to create a market where providers compete on – and are rewarded for – quality."

This document summarises the current status (at early September 2019) of NHSi's plans for electronic rostering, job planning, junior doctor and related services and Rotamap's views on these plans as a specialist Software-as-a-Service (SaaS) provider of electronic rostering services for doctors. We have also included some notes about the conformity of our services to the standards.

NHSi's new standards

On 20th August 2019 NHSi released several documents setting out guidance and/or requirements for Trusts to:

  • Ensure that services they procure meet a minimum feature set
    The Levels of Attainment (LoA) documents set out Meaningful Use Standards (MUS).
  • Procure services via fair contracts for a transparent price
    Set out in the Contract Guidance documents
  • Ensure that services they procure interoperate via a common data standard
    Described in the Software Requirements Specification (SRS) documents and other API documentation still in development

The Levels of Attainment (LoA) documents are:

  • E-rostering LoA: Published in June 2019, this sets out various 'meaningful use standards' that a Trust needs to achieve with its use of e-rostering services to progress through the e-rostering levels of attainment
  • E-job planning LoA: Published in June 2019, this sets out various 'meaningful use standards' that a Trust needs to achieve with its use of e-job planning services to progress through the e-job planning levels of attainment

The current Contract Guidance documents:

  • Contract guidance: Published in July 2019, this provides guidance for Trusts, designed to help them enter into fairer and more transparent contracts with service providers.

The current supporting software requirements specification (SRS) documents are:

  • Software requirements specification: Published in July 2019, this sets out the high level core functionality and interfaces that individual services need to provide as part of the Trust overall system, making use of the proposed common data standard.
  • Appendix A - e-rostering requirements specification: Published in July 2019, this sets out specific functionality requirements for a Trust e-rostering system. These system requirements can be provided by a combination of multiple specialist services.
  • Appendix B - e-job planning requirements specification: Published in July 2019, this sets out specific functionality requirements for a Trust e-job planning system. These system requirements can be provided by a combination of multiple specialist services.
  • Appendix C - junior doctor module requirements specification: Published in July 2019, this sets out specific functionality requirements for a Trust junior doctor module. These system requirements can be provided by a combination of multiple specialist services.

It is important to note that the NHS's concept is not only for certain standards of operation of services and their widespread adoption in Trusts, but that each Trust has the responsibility of composing a composite 'system' out of its chosen services. The Software Requirements Specification (SRS) describes the idea of an overall 'system' to be created at each Trust, which does not have to "be provided as a single application or as a single system by a single supplier". The individual component parts of the system (or modules) should be capable of communicating with each other in an integrated and interoperable manner by means of application programming interfaces or APIs.

Crucially, the technical standards underpinning the interoperation initiative – the APIs – have not yet been defined, and NHSi only expects to provide a full draft of these standards towards the end of 2019.

Rotamap is a provider of doctor rostering services at over 100 UK Trusts. We are members of the NHSi Supplier Reference Group, and are working with clients and potential clients to map the requirements to our services and modify them where required to meet the new standards. We are committed to adopting the new standards and consider that the proposed interoperability plans, if robustly implemented, are likely to encourage many more specialist services to be created for the market, increasing diversity, lowering cost and improving quality.

Levels of Attainment and Meaningful Use Standards

NHSi have designed five Levels of Attainment that they intend to use to assess a Trust's progress in implementing parts of its system, such as job planning or rostering. Each level consists of several separate but related meaningful use standards which comprise a mix of features that services must provide and policies a Trust must have in place. A Trust cannot progress to the next level before achieving all of the meaningful use standards on their current level.

Following analysis of our services' conformance to the Rostering Meaningful Use Standards (June 2019) with a partner Trust we consider that we can help Trusts meet the following attainment levels for e-rostering for doctors:

  • 80% of level 1
  • 80% of level 2
  • 100% of level 3
  • 100% of level 4

Some notes about each level of attainment are set out below.

Level 0 : No attainment

Rostering software covers less than 90% of staff.

Level 1 : visibility of staff

The level requires 90% of staff to be visible on the system, and for policies to be in place for use.

We consider that we meet about 80% of the requirements for level 1 for doctor rostering. This will rise after our present work to link to payroll systems (including ESR) is complete.

Of note, standard 1.2 requires that all staff using the e-rostering software have been appropriately trained. We provide all necessary training for staff both during implementation and for anyone who has joined after the initial implementation and training.

Level 2 : timetabling

The level covers the service capturing personal working patterns, automatic generation of rosters and publication deadlines, the clear identification of unfilled sessions and the reporting of KPIs.

We consider that we meet 80% of the requirements for level 2 for doctor rostering. Of note:

  • Standard 2.1 requires access via a remote applications, which we meet as a cloud-native service provider.
  • Standard 2.3 requires final roster publication at least 6 weeks ahead of the roster start date, which our services help departments do.
  • Standard 2.4 requires integration with temporary workforce software and applications. This is contingent on the common data standard and related API documentation being published by NHSi.

Level 3 : Capacity and Demand

The level covers the analysis of team capacity and demand.

We consider that we meet 100% of the requirements for level 3 for doctor rostering.

Of note:

  • Standard 3.1 requires teams to analyse capacity and demand using reports from their e-rostering service (among other sources). Our services provide various reports that inform this process including spreadsheets, heatmaps, p-charts, demand vs achieved comparisons and other forms of visualising the data.

Level 4 : Organisational accountability

The level sets out the need for board-level accountability for monitoring ensuring audit and review; alignment between team and Trust objectives.

We consider that we meet 100% of the requirements for level 4.

Of note:

  • Standard 4.1 requires board level accountability for monitoring e-rostering, which fits with our implementation monitoring approach. Additionally, our Central Reporting service assists in the real-time assessment of all Rotamap service rotas in real time.

Contract Guidance

The NHSi has issued specific guidance for Trusts to procure services via transparent and fair contracts on July 2019.

The guidance sets out recommendations for transparent pricing, training to be included in system costs, shorter term contracts, licence flexibility, no charges for access to the Trust's own data, and clear exit arrangements. Also, full disclosure of all system costs are recommended, amongst other data and security recommendations.

Rotamap considers it has very good conformance with most of the recommendations of the guidance. For example, our pricing is all-inclusive and transparent, and procureable directly through the Digital Marketplace. Deployment, training and support are all included, as are data exchange, messaging and exit arrangements.

We address other issues identified by NHS Improvement in consultation with NHS Trusts as set out in the guidance as follows:

  • Contracts of varying length (2-5 years) without a break clause
    Our standard agreement is on an annual rolling arrangement, with longer contracts available at the department or Trust's discretion (such as our 3 year agreement or the 2+1+1 arrangement available on the Digital Marketplace).
  • Data not backed up
    Data is backed up using multiple redundant techniques.
  • No arrangement for integration with other systems
    We have a readable API for integration with other services.
  • Inflexible licencing
    Our licencing allows for fluctuations in staff numbers.
  • Charges for return of trust data
    There are no charges for the return of data to the department or Trust (all data is already owned and controlled by the department or Trust, we merely process it for them).
  • No clearly defined exit arrangements or costs on exit
    Exit arrangements and retrieval of data (at no cost) are included in the terms of our contracts.

The guidance allows for inflationary cost increases, specifically linked to RPI. Where Rotamap contracts contain an escalator it is linked to CPI with a minimum rate of 2.5%. RPI is often higher than CPI, and has only been below 2.5% for one month since December 2016.

The guidance also suggests using milestones with pre-agreed success criteria that are subsequently linked to payment. It is not clear how milestone-based payment might sensibly work when deployment is heavily dependent on Trust staff availability and reliant on clinical engagement and other human factors.

Interoperability and the common data standard

NHSi's Software Requirements Specification states that different services or components within an overall Trust system need to work together via several core interfaces. This proposed interoperability is the cornerstone of their Workforce systems strategy, but has been heavily delayed while the common data standard and associated APIs are conceived.

Rotamap already provide a public API, and we are strong proponents of encouraging data exchange through standardised APIs. However, after correspondence with the head of the NHSi Workforce initiative Andy Howlett (Clinical Productivity Operations Director), we believe there are several problems with the approach NHSi are taking to designing an NHS-wide set of protocols:

  • The standard is late, and the draft standard is now only due by the end of 2019
  • It doesn't include any interfaces for leave management
  • There is a fundamental requirement for a unique identifier for each person in the system, and the precise origin and specification of this unique identifier has not been set out
  • The proposed system interactions are presently based on a transactional, messaging architecture based on an event-driven model which is not appropriate for internet connected systems which may suffer temporary failures
  • The proposed architecture will not allow new providers to extract historical information from existing systems
  • The proposed specification of planned and achieved work is inadequate to model complex types of repeating work, for example the data model only details 'in-month' work whereas many doctors work on weekly or fortnightly repeating cycles
  • The proposed architecture is based on a single provider covering the e-rostering component for a Trust, which does not consider the role of specialist systems

It is also notable that services are required to implement the existing CSV/file-based protocols to work with the Electronic Staff Record (ESR) service over ftp or sftp, and will not be able to use the NHSi's common data standards for ESR interactions.

Trusts using our systems have API access to their data as part of our service. Presently our APIs cover rota and leave information, and are read-only. Extending API coverage of our systems to be read-write and to cover the new areas required by the NHSi will take time and effort. We need to wait for more details from NHSi, and hopefully the resolution of the issues mentioned above, before considering in detail the work to meet the standards. We are working on ESR integration and intend to provide this at no additional cost to Trusts.

Software requirements specifications

The NHSi's e-Rostering Requirements Specification sets out minimum feature sets that any e-rostering software service should provide.

While some of the features seem sensible and obviously fit in to the Secretary of State for Health's vision (such as "DAT001 - All data must be stored securely"), others are vaguely phrased or might only apply to a specific subset of the workforce (such as "APL013 - The system must allow for role-based configuration of rules and violations eg to set a rule as a warning for managers, but violation for staff").

As well as introducing uncertainty through ambiguity, there is the danger that specialist providers will need to spend time working on features designed to meet these requirements rather than functionality needed by the teams using the software.

Conclusion

Overall, our view is that the NHSi's initiative, as currently described and if well implemented, should be good for the market, encouraging Trusts to use a larger variety of specialist providers with confidence that services can be expected to work together, and reducing the cost and effort of such a move.

However, Trusts are likely to be confused about how the overall "system" should function, which could work against the aim of creating a dynamic ecosystem of specialist services. Also, while Andy Howlett of the NHSi has assured us that the Trust composite "system" is not required to be made up of monolithic parts (for example, just one rota provider for all staff in the Trust), how specialist providers are meant to integrate is not an explicit part of the standards.

Our major concern is in the area of interoperability. The APIs are the cornerstone of the NHSi's initiative but the specifications for these are late. Importantly, we believe them to be in ill-conceived in some areas. Additionally, the outdated ESR interfaces are difficult to work with.

Rotamap's contracts and pricing are already transparent and available via the Government Digital Marketplace. Our services also go a long way towards helping Trusts progress through the levels of attainment. We look forward to working with Trusts to provide more complete conformance with the standards and working with the NHSi to improve the proposed APIs ahead of implementing these.

articles