Technology for RPA
Each RPA vendor has their own nuances and varied nomenclature, but all products comprise of three fundamental elements such as RPA development tools, robotic control centre and RPA run time.
The components shown are described in more detail as follows.
1. RPA development tools
Recorder: The recorder is the part of the development studio that developers use to configure the robots. It is like the macro recorder in excel, the bot recorder in any platform, records steps. It records mouse and keyboard movements on the user interface (UI) and this recording can be replayed to do the same steps again and again. This enables rapid automation.
Extension and plugins: Most platforms offer many plugins and extensions to ease the development and running of bots. In many applications, such as EPR or oracle finance , it is not easy to individually identify controls of the UI through traditional techniques. RPA vendors have developed plugins and extensions to help with these issues.
Workflow designer: The workflow designer is used by developers to create robot configuration or train the robots. Using the development studio, a set of instructions and decision-making logic is coded for robots to execute. Some platforms provide flow-charting capabilities such as Visio, so it becomes very easy to plot steps in a process, whereas some other platforms require coding. In most studios, in order to do commercial development, developers need to have a fair amount of knowledge of programming – for example, loops and variable assignment amongst others.
2. Robot control centre
Robot control centre provides robot management capabilities. It monitors and controls a robot's operation in a network. It can be used to start/stop robots, make schedules for them, maintain and publish code, redeploy robots to different tasks, and manage licenses and credentials.
3. RPA run time
Once issued their instructions, the software robots (also referred to as “clients” or “agents”) carry them out, interacting directly with enterprise applications to process transactions. The list of actions that a robot is capable of performing can be provided out of the box or actions can often be custom created using code.
Additional components include:
A set of tools to support compliance or any regulatory requirements and provide audit of actions taken and decisions made.
The applications, including EPR, finance, procurement, other clinical and non-clinical systems, that belong to the organisations which are integrated with RPA for workflow orchestration.
Choosing the right tool
There are various RPA tools in the market, at a high level, preferred tools should have the following characteristics:
Ease of use
Tools should not be restricted to only users with technical skills, they should be versatile enough to be usable by clinical, operational and technical users. These tools should also have the capability to collect data that empowers leaders to make informed decisions.
Teams will benefit from choosing an RPA platform that can be easily centrally managed and rapidly scaled to as many different locations as necessary.
As RPA will automate key tasks and processes, its critical for the teams to consider the reliability of the solution and built-in monitoring with analytics.
The best tool will let the teams design and test new robotic processes very rapidly. The tools should also have the ability to act on initial performance feedback quickly to optimise the bots.
The best tools support simple, task-based activities, read and write to any data source, and utilise advanced learning to improve future automations.
Key attributes that organisations need to look for in RPA software are summarised below.
- The tool should be designed to provide organisations with a business owned and IT-supported virtual workforce
- The tool must offer a software platform which is robust, highly scalable, powerful and flexible
- The tool must provide central management of robots and analytics dashboard for insights and utilisation
- The tool must include out-of-box software robots and ability to custom build software robots to automate end-to-end processes, supported with cognitive capabilities such as continuous learning and improvement using data/analytics
Compatibility with existing estate
- The new RPA software need to be compatible with existing clinical and non-clinical systems – for example, finance and HR systems, trust integration engines, EPR, pathology and radiology information systems
- The vendor must provide a list of potential compatible healthcare systems and must need no or minimal configuration work for those systems
- The tool should be capable of extracting and integrating data from different data sources and systems
- The software should be able to read and write different document types
- The software must provide the ability to be hosted either a desktop, a on-premises server, a public or private or hybrid cloud
- The software must provide an intuitive visual interface to allow technical and non-technical users to build workflows using drag and drop style activities with minimal training
- The software must provide the ability record process steps for functions so that the bots can follow these steps and execute tasks
- The software must include a workflow manager which can create the workflow for multiple bots and link them through a task chain
- The bots must understand the data and objects on the screen, so that it's easy to handle any changes in the application
- The software must provide the ability to record multiple activities at once
- The vendors must provide pre-built connectors for the software that can easily integrate with key applications in the enterprise
- Robots can be scheduled, placed in queues, triggered set a predetermined times, initiated by humans, or actively monitor databases to activate
Detailed assessment will be required against NHS specific standards, for example, NHS RA and information security standards.
- The software must provide the ability for multiple bots to share architecture with central control
- The vendors need to ensure the software is aligned with NHS data privacy regulations and data is kept within country boundaries in line with GDPR regulations
- The solution using the software is architected for enterprise-level security, compliance, support and audibility
- The software must provide security features to ensure only authorised personnel of the enterprise can access or manipulate data
- The solutions built using the software must provide high level of flexibility for encrypting the data at rest (data storage) as well data in motion (API’s and messages)
- The software must have the ability to execute unlimited business processes with a single bot for greater scalability
- The software supporting the bot must have built-in objects and libraries that organisations can reuse in order to support scaling up of processes and automation can be scaled up or down according to business needs
- The software must provide flexibility to adjust the number of resources assigned based on business demands
- The Software need to offer 4 levels of integration – user Interface, API, operating system level and database level to support scaling up automation based on the enterprise needs
- The solution built using the software needs to provide multiple error handling options to users when changes occur in automated processes
- The software needs to provide the ability to easily track errors, provide alerts and recommend changes to processes
- The software needs to include controls for exceptions which can be configured easily and trigger notifications as needed
- The software need to provide the option to flag and notify the administrator any change in the processes and allow to continue or terminate depending on pre-set rules or administrator action
- The vendor needs to support the ability for their software to be hosted either on-premises by the organisation, by a managed service provider in partnership with the RPA provider, or on a public cloud such as Azure or AWS
- The software must be able to automate software maintenance and need to provide backward compatibility with software versions
- The vendors license model should be flexible and include SaaS-based platform as well
- The software must be able to handle changes to automation scenarios in the bots due to application version updates. It also needs to support changes to the processes and quickly save the changes to the server to make them available for bots and making change management easier
Centralised control and analytics
- The control room in the software must provide visibility and control from a single dashboard to schedule, track, verify, log, organise and report on all automation activity, allowing enterprise user to maximise the benefits of automation
- The software bots must be able to capture all content-level information so that every action on all the bots would yield real-time process statistics and operational analytics for the digital workforce
- The software Bots must help optimise processes and provide RPA reporting
- The software must support enterprise users to track KPIs and cost savings through automation and monitor individual worker and entire workforce performance
- The software must provide the ability to monitor and audit trail the users and bot activities though control centre
- The software must display both scheduled and failed tasks
- The software must document any failure for future audit needs
- The software must provide a detailed log sheet which provides a time-stamped history of every action and decision that is taken
- The software must be able to use visual/image recognition technology to see screen elements just as humans do
- The software must provide the ability to use machine learning for semi structured processes that typically need expert decision making
- The software must provide the ability to use natural language processing for analysing natural written language text and documents
- The solution developed using the software must ask for human assistance when it encounters something it cannot understand and will learn from those escalations to continuously improve its ability to automate similar tasks in the future
Training and support
- The RPA vendor should offer in-house, on-premises and online (interactive and on demand) training sessions and tutorials
- The technology provided by the user should be user-friendly so that minimum support is required to create bot process flows
- The buyer should discuss with vendor annual licensing model with the ability to buy additional bot licenses varies depending on the requirement
- The buyer should also consider per-transaction and usage-based licensing model
- The software vendor should not add any additional charges for the server component or any centralised functionality
- The software vendor should make sure any maintenance and support costs are included in the pricing and clearly stated, if charge additionally
- The software vendors should be aware that the NHS owns IP for automation developed by them for the buyer using the bot software
NHS specific compliance requirements that need to be considered for any RPA implementations are as follows:
Medical device regulation
The 2002 UK Medical Device Regulations apply to all products qualifying as a medical device or in vitro diagnostic medical device (henceforth we mean both by ‘medical device’). All digital technologies classed as medical devices must meet the relevant requirements of the regulation and have a UK Conformity Assessed (UKCA) mark in place before they can be placed on the UK market, please note that an up-to-date CE mark will continue to be recognised until 30 June 2023. The Medicines and Healthcare Products Regulatory Agency’s (MHRA) medical devices flowchart helps developers of digital health technologies understand if their technology is considered a medical device under the 2002 UK Medical Device Regulation.
It is the responsibility of the legal manufacturer to determine if the implementation of automation falls within scope of the above regulations. Assessment of whether an automation qualifies as a medical device or not can be complex and must take into account the wider context of the automated process. Additionally, this assessment is made more complicated, as automation that utilises a known medical device may then themselves be an accessory to a medical device. It is advised that trusts contact their compliance or medical physics/clinical engineering department for clarification. In case of uncertainty, please contact the MHRA.
Clinical risk management
NHS digital information standards on clinical risk management in digital systems is designed to help health and care organisations assure the clinical safety of their health IT software. These standards provide a set of requirements to promote and ensure the effective application of clinical risk management by:
NHS digital technology assessment criteria
NHS Digital Technology Assessment Criteria for health and social care (DTAC) gives staff, patients and citizens confidence that the digital health tools they use meet clinical safety, data protection, technical security, interoperability and usability and accessibility standards.
NHS identity and access management
Any RPA deployment involving NHS Spine must use APIs or the NHS’s PKI based identity management capability (approximately 900,000 smart card users) which handles identities for real people based on international PKI standards.
NHS Digital RA and Cyber Security have developed an assessment framework to enable each RPA deployment solution request to be assessed on a case-by-case basis for RA and Information Security Controls. If the controls and risk and mitigation assessments are considered satisfactory, a time limited deployment will be agreed as an exception to NHS RA Policy.
Information governance requirements are specific to each trust or local authority, which may include completing data protection impact assessments (DPIA) for each technology being commissioned.