Transformation Directorate

Getting started with RPA

Identify the right capabilities

RPA programmes should align with organisational priorities which may differ between clinical and non-clinical teams. There are key questions that need to be considered to set up the right strategy and processes to deliver right outcomes.

Phase 1. Designing capability

Setting vision and strategy for RPA

  • What are the key drivers for automation?
  • What are the specific pain points we are trying to address?
  • Where will we focus first?
  • Do we have a mechanism in place to identify opportunities for proof of value?
  • What is our methodology to conduct process performance and volume data analysis on identified opportunities?
  • Is there a wider benefits case for the target area? How can we secure sponsorship and funding to deliver that?
Phase 2. Delivering capability

Mobilising proof of concept

  • How will we identify the best opportunities for proof of concepts to prove value of RPA?
  • What is the platform and infrastructure that we need to enable the proof of concepts?
  • Have we engaged the relevant stakeholders from clinical and non-clinical teams? Do they have the bandwidth to support the programme?
  • Do we have the right resources for delivery team and support from IT to provision RPA tooling?
  • Do we have a plan for change management to enable adoption?
  • Did the benefits realised align with benefits planned? What is the feedback from the staff and the patients?

Scaling using automation target operating model

  • Do we need an RPA Hub or a capability centre?
  • What model of automation target operating model will serve our staff and needs best? for example, centralised versus hybrid versus decentralised versus bespoke
  • What is the scope of services and capabilities they should have? for example, internal capability versus internal or external third party service providers
  • What is the target benefits case across the clinical and non–clinical functions? Do we have the right resourcing and infrastructure to deliver the same?
  • Do we have established methodology and frameworks for ongoing discovery, triage and development to maximise utilisation levels of established RPA infrastructure and teams?
Phase 3. Sustaining capability

Digital work industrialised

  • How will ongoing bot monitoring and performance optimisation work?
  • What are the key performance indicators (KPIs) and service level agreements (SLAs)?
  • Do our staff know what to do in case of any issues with the bot(s)?
  • Do we have operational governance and patient safety controls in place?
  • Do we have a process for incident management, platform maintenance and support?
  • Have we set out alerts, KPIs, reports, stakeholder communication and operating rules?

Readiness to deliver

It's also important to identify and understand the key roles, skills and technology required to determine investment scope, and set up and deliver.

Phase 1. Designing capability

Skills required

  • Project or programme manager
  • Business or process analyst
  • Automation architect
  • Integration architect
  • Security architect
  • Plan for resource training, upskilling, recruiting


  • Platform
  • Process mining and process discovery
  • Virtual desktop infrastructures (VDIs)
  • Hosting (cloud/on-premise)
Phase 2. Delivering capability

Skills required

  • Project or programme manager
  • Business or process analyst
  • Automation architect
  • Software designer/developer
  • Delivery manager
  • Quality assurance analyst
  • Change manager


  • Platform
  • Virtual desktop infrastructures (VDIs)
  • Hosting
  • Development licenses
  • Test licences
  • Production licences
  • Controller/orchestrator
  • Elastic search (logging)
  • Active directory (users)
Phase 3. Sustaining capability

Skills required

  • Performance analyst /resource manager
  • Bot farm manager
  • Bot controller
  • Bot administrator
  • Infrastructure manager
  • Service manager (support and helpdesk)


  • Scaled platform and infrastructure for bot farm including VDIs, development and test licences, and production licences
  • Automation management hub for bot farms
  • Service management infrastructure (helpdesk, incident/change management)
  • Automated monitoring and orchestration tools
  • Hosting

Disclaimer: These skills could be developed in-house. Alternatively, teams could engage external providers/suppliers, subject matter experts (SMEs) or a combination of two in a hybrid delivery model.

License types

Licensing for RPA can be complex as the nomenclature and pricing model can vary widely. The typical license types are described below:

Unattended license

Unattended bots perform tasks without human intervention. Single unattended bot license can accommodate one or multiple unattended bots based on volumes and frequency required by the use case.

Attended license

Attended bots are typically individual bot assistants programmed on user machines and are specific to that user. Every attended bot will require a separate attended license.

Non production license

These licenses are required for testing the workflows in non-production environments such as developing/test environments. They cannot be used for production bots. Every team will typically need to buy some of these for testing activities, so don’t forget to account for the cost of these on top of your production licenses. These should always be lower than your production requirement, as they would typically not handle the full processing volumes at once.

Production license

These licenses are required at the time of going live or productionising the bots. You would need to determine the number of production licenses required by looking at the processing volumes and the uptime of the bot, just as you would calculate staff required to meet the demands of a process by considering total demand and working time the staff is available for.

Studio or developer license

These are non-production licenses used by developers to access development studios for the RPA software providers. Every developer typically requires a separate individual license, but some vendors offer concurrent usage licenses as well, however the price of the two may vary.

Several vendors are now offering different types of studio licenses varying from ones catering to traditional technical developers to low code studios targeted at citizen developers who do not have the technical coding skill set; for example, UiPath offers 3 types of studios, Studio, Studio X and Studio Pro.

Bot controller or bot runners licenses

These are controllers that provide remote monitoring and management of the bots or digital workers. All the bots can be connected to the controller(s) and controller(s) will manage the triggering and schedule of the bots. Controllers can manage multiple bots, but the number can vary by provider. You would also need to account for a non-production license to ensure you can conduct testing effectively

When starting with RPA

Leverage the NHS’s current co-existing architecture

Once the priorities have been established and tooling and resourcing identified, there are multiple entry points to starting your RPA journey.

A hybrid approach encourages flexibility and provides the opportunity to adopt one, or multiple approaches, depending on your organisational needs and local priorities.

ICS Supported

  • Regional approach
  • Scalable
  • Economies of scale
  • Communities of practice 

RPA Hub Supported

  • Building on lessons learned from colleagues across the healthcare ecosystem
  • Working with existing NHS hubs

Commercial Partner Supported

  • Working with vendors and advisory partners
  • Technical expertise
  • External SME and cross-sector insight


  • ICS: integrated care system made up of multiple organisations providing care.
  • RPA hub: referring to organisations that have mature RPA programmes and have been designated RPA hubs within the NHS network.

Consider the pros and cons of different models

Each option in the hybrid model has pros and cons to consider.

Hub supported approach

There are multiple examples of hubs and good practice in place across the health ecosystem that can provide guidance and advice to organisations planning and mobilising their own programmes. When designing and mobilising RPA programmes advice, guidance and support can be sought from these hubs to ensure knowledge transfer across the system.

Pros and cons


  • Access to established processes, frameworks, governance and resource that have been tried and tested within the NHS
  • Teams might be able to run test use cases on hub infrastructure and benefit from existing license capacity as, typically, that is the largest capital investment that teams need to make upfront
  • Teams may be able to benefit from the combined scale of NHS requirements to get the best deal on RPA licenses and services


  • Depending on the size of hubs and current backlog of work, they might need to prioritise who they can support and when

Integrated care system (ICS) supported approach

The NHS Long Term Plan confirmed that all parts of England would be served by an integrated care system from July 2022. ICSs offer an opportunity to design solutions and invest at scale across regions. Working with ICS colleagues to define your RPA programmes provide opportunities for efficiency gains and benefits leveraging the scope of activities across the organisations.

Pros and cons


  • This approach will allow addressing end-to-end patient journey to ensure seamless handoff of patients from one care provider to another and avoid disjointed experience across different verticals of care
  • Provides better economy of scale and allows effective knowledge sharing and integration within an ICS


  • Disparate IT systems across ICSs will increase build complexity and stakeholder management, as multiple approvals might be required from multiple IT teams to access applications

Commercial partner supported approach: advisory partner

Several advisory support / consulting partners are a one-stop shop that can provide end-to-end services and expertise including infrastructure, design, development, run support and licenses. They are also adept at helping programmes understand what exactly they may need depending on their strategy, programme maturity and individual requirements.

Pros and cons


  • Leverage build and run skillset, infrastructure and license to test the solution
  • Investigate the potential of RPA across the function/organisation and build a benefits case to justify further investment
  • Test the solution to de-risk longer term investment and commitment
  • Outline capabilities required to stand up the programme and plan for transition from external support led to internally owned


  • Teams still need to procure licenses separately, however several advisory support partners have reseller agreements in place with a majority of top technology vendors
  • Additional cost to account for at the beginning of the programme

Commercial partner supported approach: product vendor

Teams could also directly approach RPA vendor(s) to discuss a delivery strategy. This will allow them to jointly outline a plan that best fits the programme requirements, while addressing any specific programme constraints.

The RPA vendors can support internal staff to build RPA capability or help engage one of the external advisory partners based on the size, scale and maturity of the programme, and specific programme requirements.

Pros and cons


  • Might be cheaper to access initial support compared to a consulting partner advisory


  • Any advisory support will be limited to more technical aspects of the programme
  • Potential to get locked into a product without having had a chance to complete market research and analysis

After starting with RPA

Build a benefits case

RPA will drive reduction in operational costs and costs of care delivery. But to develop a comprehensive benefits case, organisations should look at all clinical and non-clinical outcomes.

Operational benefits include:

  1. Increased operational capacity and speed.
  2. Patient and treatment backlog reduction.
  3. Reduced cost of care by reducing cost of delivery.
  4. Faster turnaround.

Patient safety outcomes and experience include:

  1. Improved patient journey and experience.
  2. Better, faster and seamless delivery of care.
  3. Increased time for care due to reduction in admin and manual activities.

Staff benefits include:

  1. Improved staff engagement.
  2. Improved staff experience by enabling them to focus on value-added activities.
  3. Reduced attrition and burnout. Staff sickness or staff satisfaction.

Process efficiency benefits include:

  1. Improve care quality and patient safety by reducing operational risk and variability.
  2. Manual and transactional activities, and tasks get done quicker while also reducing human error.
  3. Reduced process variability

Join the NHS National Community of Practice for RPA to access examples of Benefit Case, Benefit Framework and ROI.

How to build a benefits case

For a comprehensive benefits case, a ‘total cost of ownership’ view should be taken to ensure all cost and benefit aspects of the solution have been identified and accounted for.

Step 1. Conduct process performance analysis

Once a target use case has been identified, conduct as-is volumetric analysis to outline data, metrics and KPIs for the use case.

Step 2. Identify and outline benefits

Every team and organisation may have a different driver for RPA; identify all the benefits that RPA will enable for your organisation and use case.

Step 3. Quantify benefits

Quantify the benefits identified in step 2, using the data collected in step 1; account for cost of delivering and managing the automated solution.

Step 4. Validate

Once the benefits have been identified and quantified, validate the data, assumptions and final benefits case, both from an operational and financial perspective.

Step 5. Track and manage

Benefits case should be monitored and reviewed at the delivery stage to ensure that assumptions, metrics and KPIs are still applicable

Top tips

The benefits case should ideally be analysed, managed, reviewed and audited at an opportunity as well as the programme level. RPA creates a dependency between two or more systems which can lead to systems becoming embedded, making change harder, more expensive, and riskier, which in turn can lead to legacy systems remaining in place for extended periods of time.

RPA also reduces the benefits case for upgrading legacy apps. Organisations should review long-term IT roadmaps and create and risk assess short- and long-term benefits cases to ensure RPA is leveraged at the right time for the right use cases.

Transitioning from RPA programme delivery to RPA service

After the bots have gone live, they need to be managed like any other software solution. Hence, it is important to consider what an RPA service model will look like. The service wrapper needs to carefully consider business as usual requirements and business criticality. Fall back options and service level agreements (SLAs) should be planned by engaging the right business, clinical, frontline and/or support staff to ensure they are in line with how the bots will be used.

Engage an external partner, commission from third parties within the NHS, establish your own

Engage an external partner

There are a variety of external partners that provide services to run and maintain RPA services of varying size and scale. These include traditional consulting firms, business process outsourcers, information technology services firms, niche RPA consulting firms as well as specialised companies that just run and manage bot farms.

Depending on the scale of their RPA programmes and vision for growth, teams can approach one or more partners to understand services provided and associated cost models.

Pros and cons


  • Plug into existing service, reducing lead times to establish the capability
  • Benefit from deep expertise of providers that have significant experience of setting up, providing and running bot farms
  • Ability to scale quickly


  • External spend will require additional internal procurement approvals and processing
  • Will still require an internal service manager to manage the contract and service

An external third party will need to get access to orchestrator and potentially the bots, depending on the scope of services.

Commission from third party within the NHS

There are several pockets of RPA service capability across the NHS, both at an organisation and regional levels, such as ICS. Their capabilities ranges from project teams following the principle, “If you develop it, you run it” to organisations that have procured fully managed services provided by an external partner.

Teams that are just starting their RPA journey could explore whether hubs or partners at a regional level can provide third party services to manage their bots, or if they can benefit from scale of those that have commissioned external providers.

Pros and cons


  • Plug into existing service reducing lead times to establishing the capability
  • Leverage the scale of consolidated regional volumes for better deals on software /resources / technical or advisory support, if required
  • Ability to scale quickly
  • Reduce the risk of duplication across the sector


  • Limited by existing service model, service framework, prioritisation and SLAs
  • Might require integrating systems between the organisation seeking support and the one providing, increasing the resource and time requirements to setting up the service
  • Challenges with general data protection regulation

Establish your own

Teams can look at expanding their internal capacity to account for roles and capabilities required to run and manage their RPA bots or digital workforce, and transition to a fully managed service like other IT applications or systems. The full range of service components that will need to be developed and delivered are outlined in section 4 under the ‘Release and Embed’ section, for reference.

This service will be outside of the scope of project delivery team once the hypercare* period has been completed – hence the teams should plan for this at the onset of development.

Note: *Hypercare is user-centred support during a critical period in the project lifecycle

Pros and cons


  • Business and project teams’ proximity to service leadership
  • Service teams will develop better understanding of internal processes and functions, helping them provide better run support
  • No prioritisation required given the internal dedicated nature of the service


  • Longer lead times to developing and establishing the capability fully
  • Increased investment in the programme
  • Initial utilisation of teams might be low as the programme scales
  • Limited ability to scale rapidly

Procuring RPA

To procure RPA software and services, organisations will first need to determine the procurement category pillar the requirements will fall under. All six pillars have been described below. Any product within these pillars must meet the minimum standards defined.

Pillar 1. Clinical hardware

Tangible hardware items, that may be governed by MHRA Regulations and can only be used in a specific clinical setting, use case or environment. Such as, but not limited to, all-in-one medical computers/theatre consoles, radiology workstations and biometric medical items which are not included within a medical or clinical device category (covered by MHRA and NICE). Irrespective of whether procured as assets or subscribed Device as a Service (DaaS).

Minimum standards

  • MHRA compliant
  • Ethical or Sustainable Standard compliant
  • Current OS “N” minus One compliant
  • Cyber Essentials accredited
  • Or ISO 27001 accredited
Pillar 2. Non-clinical hardware

Tangible hardware items, which can be used in any setting, sector or use case and are not covered by MHRA Regulations. Such as, but not limited to, end user computing and mobile or tablet devices and peripherals, printers or multi-function devices, physical servers and physical networking equipment, wireless access points and controllers, smart screens and white boards, reception consoles, and information screens. Irrespective of whether procured as assets or subscribed Device as a Service (DaaS).

Minimum standards

  • Ethical or Sustainable Standard complaint
  • Current OS “N” minus One compliant
  • Cyber Essentials accredited
  • Or ISO 27001 accredited
Pillar 3. Clinical software, SaaS and apps

Software solutions, applications or Mobile Apps used in patient care in any setting/sector, including any system of record which may contain elements or all of a patient’s record, consultation notes, treatment plan and prescriptions. Whether procured as remotely, or cloud hosted, 'on premise', licensed or Software as a Service (SaaS).

Minimum standards

  • NHS number as core data record
  • Web based user interface
  • GDPR compliant
  • Cyber Essentials accredited or
  • ISO 27001 accredited
  • Cloud Native with UK based hosting location(s)
  • Open APIs
  • HL7 compliant
  • FHIR Standard compliant
  • DCB0129 compliant
  • SNOMED CT and/or ICD10 compliant
Pillar 4. Non-clinical software, SaaS and apps

Software solutions, whether procured as licences or Software as a Service (SaaS), that can be used across a range of non-clinical or back office settings, such as finance or procurement, human reosurces, payroll, information governance and risk, Legal services or IT services management systems, and business intelligence or analytical. Also includes RPA, digital dictation or transcription services, and other applications and mobile apps which may support the utilisation of the software solutions used in this pillar. Whether procured as remotely or cloud hosted, 'on premise', licensed or Software as a Service (SaaS).

Software solutions, whether procured as licences or Software as a Service (SaaS), that can be used across a range of non-clinical or back office settings, such as finance or procurement, human resources, payroll, information governance and risk, Legal services or IT services management systems, and business intelligence or analytical. Also includes RPA, digital dictation or transcription services, and other applications and mobile apps which may support the utilisation of the software solutions used in this pillar. Whether procured as remotely or cloud hosted, 'on premise', licensed or Software as a Service (SaaS).

  • GDPR compliant
  • Cyber Essentials accredited
  • OR ISO 27001 accredited
  • Cloud Native with UK based hosting location(s)
  • Open APIs
  • HL7 compliant
  • NHS national RA policy
Pillar 5. Clinical services

Electronic assistive technologies (EAT) such as for environmental control systems and alternative means of access for complex disabilities; alarm technologies and services that support remote monitoring, enable supported living (for example, fall monitoring); continuous monitoring services to enable clinical diagnosis of patients at home; scheduled and on demand remote services to manage and control chronic illness (TeleHealth, TeleConsultation); medicine optimisation services.

Minimum standards

  • Ethical or Sustainable Standard compliant
  • Cyber Essentials accredited
  • OR ISO 27001 accredited
Pillar 6. Non-clinical services including IaaS and PaaS

6a. Network and Hosting

Intangible solutions such as, but not limited to, mobile data, networking, cloud hosting, Infrastructure as a Service (Iaas), Platform as a Service (PaaS), telephony lines.

Minimum standards

  • Ethical or Sustainable Standard compliant
  • Cyber Essentials Accredited
  • Or ISO 27001 Accredited

6b. Complimentary Technology Solutions

Intangible solutions such as, but not limited to, cyber security or penetration testing services, data analysis or business intelligence services, technical support or data migration services.

Minimum standards

  • Ethical or Sustainable Standard compliant
  • Cyber Essentials Accredited
  • Or ISO 27001 Accredited

6c. Professional Services and Consultancy

Professional services specifically regarding digital and technology (excluding project management or temporary staffing, which falls under workforce category) technical consultancy and advice.

Minimum standards

  • Ethical or Sustainable Standard compliant