Darren Atkins, Chief Technology Officer for Intelligent Automation at Royal Free London NHS Foundation Trust, has set up a series of live interactive sessions for all professionals working in automation, called the ‘Automation Cafe Live!’
The sessions have been set up in his own time, Darren said, “so that people like myself and people like my teams can come and talk about real world situations”, and to share insights from experiences working with automation.
For session one of the series, Darren started by sharing some of the common hurdles and barriers to robotic process automation (RPA). Often, he said, organisations invest in the technology and work with an external vendor to build the first processes, but once they are left to manage it “it’s not scalable, they lack confidence, they don’t know really know how to do it.”
Barriers often seen by Royal Free’s automation centre of excellence include process definition (what do we really want this robot to do?); being risk adverse; lack of education, knowledge and understanding of RPA; attracting talent; digital maturity; and understanding of the role of RPA within a digital strategy (RPA cannot be used as a replacement for digital strategy and interoperability – they must work together).
Next Darren turned to reflections on the maternity self-referral service he has recently worked on.
Some background information was shared for context; previously, a pregnant patient would fill in a form which would be sent by email to the maternity team, who would pick that up during their office hours, validate it, and key it into the relevant systems. RPA handles this administrative process now and is capable of validating the data, logging into the patient administration system, search for the patient or register a new account, enter the maternity encounter, and upload a copy of the email as reference. The robot will then contact the patient with confirmation and next steps. A daily report is sent to the maternity team to keep them up-to-date. Darren estimated that the RPA saves the team around 68 hours per week, allowing them to spend their time with patients or on more productive tasks.
“So what have we learned? To start with, there’s always this big debate about whether you take an existing process and just automate it, or you spent time making it lean, making it efficient, changing the process, and then automating it,” said Darren. “Actually there’s two different viewpoints – if you automate the process as it is, you’re going to be able to do it quickly, release the benefit and move on. If you change the process, you might make it more digital, more effective, but it’s going to take a lot longer.”
The maternity RPA was built on an existing online form. “The quality of the data that came through from the online form was very mixed,” commented Darren, sharing the example of date mix-ups – sometimes patients would mistakenly fill in the date that they were registering their pregnancy as their date of birth, causing confusion. “What we find a lot with some of the form-based products that we have to interact with that there are very little data quality checks at the front end. I always subscribe to the view that if you can fix the data quality at the point of entry, then it’s going to make your process so much better.” When building automation on inherited, existing forms, you can sometimes face problems like this. Darren’s team had to validate each part of the data collected from the online form whilst building their automation, checking the syntax and reformatting data.
On reflection, Darren said, “We would build a purpose-built e-form that had all those data quality standards and passed that data directly back into a robot queue… so that’s something to consider, think about your inputs to your processes, your triggers, how you can streamline that, and how you can fix a lot of the data quality issues at the front end.”
The application used for surface automation can raise challenges, including things you might not necessarily expect, such as the screen resolution. Darren described one particular problem where “the robot was struggling to tell the difference between the letter i and l, and the number one. So we had to look at resolution to resolve that issue.”
Application pop-ups can also provide barriers. Darren provided an example; when his team live-tested a process that included different scenarios such as different types of patients or different types of datasets, unexpected pop-ups would appear on screen. This led to further communication with the organisation to work out how to proceed and the code had to be re-engineered, which was not ideal at the point of testing. “I don’t know if we’re ever going to get away from identifying every possible permutation of pop-up,” Darren said. “It’s just something to watch out for. Don’t always assume that when you’ve defined the process, when you do it in a real world system, that the process is going to flow in the way you expect it to.”
If possible to do so safely and securely, Darren added, developing on a live system with live patient information leads to better quality outcome. On a test system, he said, “the data always seems a bit too pure… when you’re on a live system, you get real world experiences of differences in data.”
Another question raised was “when is a process good enough to go live?” As a technology team, Darren said, they would expect “zero system exceptions – when a robot can’t interact with an application, like it can’t find the field or can’t type something in. These are system exceptions and things that we as an IT team or technology team would resolve. There are also business exceptions. They’re not bad things, what it means is that the robot has looked at a transaction and for business reasons it’s not going to continue. It could be that the patient can’t be found on the healthcare system or the postcode is wrong. We’d mark that as a business exception for humans to pick up at the end of the day.
“The important point to note is that we’re not going to lose any of our patients along the way – that’s really critical. So when you’re designing these processes, just as much attention needs to be exception handling and reporting.”
The final challenge highlighted by Darren was that of system delays. “If you’re moving data from one system to another… [there can be] a massive delay from when we upload it to when it appeared in the patient record. Of course, RPA good practice in our world is that if you upload something, rather than just assuming it’s been uploaded, we go in and find it and check that it’s there. A lot of times, we check it and it isn’t there – is it a system fault? An RPA fault? In this example, it turned out to be a bit of a time lag.”
The key learning, Darren said, is that “automation robots run really fast, they run at machine speed. But sometimes we have to take into account some of the systems that we’re using in terms of speed, performance and functionality.”
Darren then turned to a question-and-answer session with the webinar audience, available to view on the video below at 32:35.
Darren hosts live Automation Cafe sessions every few weeks exploring different topics, interviewing special guests and interacting with the audience – keep an eye out here on HTN for more in the coming weeks.
Past episodes are available here:
To be notified when future cafes have been scheduled, you can follow Darren Atkins in LinkedIn.
