Automation in Primary Care

Introduction

I thought this would be a good opportunity to work on a blog around this topic which is very close to me, having been in the space for so long. I’m humbled that PatientChase was recently successful in a Health Innovation Network Bid to look to automate processes in Primary Care. We are looking to scale up PatientChase to a PCN and borough level to help drive an agenda of focusing on populations with Health Inequalities via Risk Stratification through intelligence analysis of drivers to determine how to help them book into clinics for proactive care via a CRM module.

However, I thought I’d take a step back and give my take on automation in primary care in general. I hope this blog may give others ideas about how we can together improve the way we work in primary care using tech as an enabler. As you work your way down this blog you should pick up on applications already in this space which help surgery efficiencies. When I first started writing this blog I thought it would be a straightforward process around explaining how a surgery works using my surgery as an example with the aim of mapping processes and giving ideas around where efficiencies can be made. How wrong I was.

The scope of this blog is around automation, so it’s important to understand, in my opinion, what this means. To me, automation applications help automate manual processes within a system, for example, automating recall for proactive care of the population. This has the endpoint of improving efficiencies in the system so we can offload important resources to fewer manual tasks. Initially, these can be simple tasks, but moving forward can be more complex with the ultimate outcome of improving surgery efficiencies. I’ll explain this with an example below around calling patients in for a flu jab.

What is a Bot?

I love it when the NHS rebrands existing items to give them new sexy names to help revitalise agendas within Health Care. They did it with Choose & Book, which was rebranded as eRS, and I also believe Quality Improvement, which is, in my opinion, just a more deep dive on PDSA Audits but with a bit more bells and whistles. It’s a cool concept to imagine a tiny little robot working inside your computer, busy replacing a manual process or processes, and from a user’s perspective, it can be useful to visualise problems in healthcare this way. I also think of nanobots which are a future concept of tiny microcomputers which are injected into the bloodstream to repair and treat patients from the inside.

In my opinion, a bot is simply a task or what developers might call a use case which encompasses an action within a real-world setting with a focus on the automation of data or user interactions. These use cases are normally manual and repetitive, and by using bots you can offload this task with higher reliability and be quicker and more efficient. Think of bots helping the process towards the goal of the outcome of efficiency gains. Now think of a salesperson who doesn't tell you that by using his application, you will improve the efficiency of your workload, so you can infer there are quite a few applications out there that use “Bots”.

However, it’s good to visualise bots in terms of atomic actions. We love to use the word atomic as a developer. It implies that this set of instructions or code does one and one thing only, which in turn will help in terms of reusing that code elsewhere and, I think, really helps the non-developers to focus on the system analysis design of a problem they would like solved. By visualising Bots you are able to break problems down into smaller actions which is what developers love to see as they can then convert these “bots” or atomic actions into real code.

So, in summary, Bots are ways in which you use tech to improve the automation of processes in the clinical and non-clinical setting. Imagine a manual process in the surgery and think about how you can automate this with software.

Processes in the Surgery

This is a flow diagram of processes in a surgery which represents the day-to-day workings of an average day. It is not exhaustive, and I might have missed some aspects unintentionally. Each line represents a process which is required to move the patient or data into the next section and is an area where we can make efficiencies through automation. If you were to think of a way to help primary care through automation, think about the lines and how you can create something to make this connection better.

For example, for my products: PatientChase focuses on the proactive caseload management of Recall via Risk Stratification and Month of Birth; PatientLeaf is more around Template, Code Data and Record History to help clinicians make more informed decisions when they see the patient in the clinic.

We need also to now think about how to manage the load by dividing patients into 2 categories.

Reactive Clinics where the patients on the day would like to be seen and how we manage this. The query can be as simple as a script request to an important symptom, but the key is demand is generated by the patient.

Proactive Clinics where we call in patients based on a pre-existing condition or targets pushed down on us by the powers above through QOF, DESs, LESs and PMS KPIs. These can also be patients who you decide to pick on internal audits, but the key is demand is generated by the practice.

Gone are the days when we were asked to do a patient’s QOF markers in the clinic. In the clinician-focused triage we live in, we either can’t (as they are on the phone with no physical presence) or don’t have the time with the volume we are going through.

Self-booking allows the patient to book themselves into clinics directly via electronic methods. It’s a really nice feature as it avoids the need for a patient to contact reception, saving time. I would strongly advocate that this should only be for proactive care where there is a defined population. Unless surgeries have the capacity you should never use self-booking for reactive care. This should be triaged. I learnt this the hard way. We were at 2-day access a few years ago, so I opened up an extra 2-hour clinic on Monday morning to help our load, not realising this clinic was open for patients to book themselves in. On Monday morning, the slots had all gone, and 90% of patients who booked were for medication issues and sick notes. Patients, through no fault of their own, want to contact their GP, and they find the path of least resistance. This is why we need responsive triage for reactive care, so what can take a minute to do on the phone won’t be wasted by a 10-minute appointment.

Cloud Triage is interesting as I think as we merge more to manage reactive care with other organisations within our PCN there will be a need to centralise the load, and it’s a direction in which we should be travelling in.

To keep it simpler External Providers represent any organisation outside general practice and can be another PCN Hub, Home visiting Service, Community Services, Hospital, Data Server, NHS organisation. Something outside General Practice which we deal with on a day-to-day basis.

Operational Systems involve everything around maintaining the organisation, which CQC would ask us.

To API or not to API

If a user is performing a manual repetitive task every day by pressing the same keystroke and mouse clicks on the computer screen it goes to reason that the perfect bot would imitate and emulate this combination. Why use a human when a bot can just copy and repeat? Unfortunately, it’s not as easy as this, and wherever possible, I’d recommend using an API (Application Programming Interface).

Let’s take an example of Dr X creating a macro to try to book blood tests electronically for his diabetic patients, a task with admin would take ages to do. He manages to emulate the staff’s keystrokes and mouse clicks and is happy with the result. However, a patient has already had his Hba1c done, so out pops a message stating that that Hba1c blood test was done recently. This would break the macro as the bot is not expecting this popup. Ok, so he manages this with a bit of tweaking and also manages Vitamin D done recently. Joy! He deploys, and the surgery is happy. Other surgeries get hold of this, and soon he’s sold 500 copies. The clinical system supplier then decides to move Hba1c on the display. Overnight he has 500 angry customers stating that their product is broken. It just takes a minor change to the screen, and everything falls apart, so it’s difficult to scale when you are relying on the supplier to keep their screens static and the same. I’m sure these issues may have been overcome by software suppliers, and wherever possible, it’s important to emulate keystrokes rather than mouse strokes and image capturing. The other positive is that EMIS probably won’t change their GUI, so you should be safe with macros (until they change their clinical system and you are at ground zero again). Also, a lot of the time, the developer of the clinical system won’t expose the automation you wish to do via APIs, so screen scrapping and macro applications are the only way to achieve your end goal.

Wherever possible, and I know this might be difficult in terms of contracts and formalising, it’s better to use an API to access data. An API is, in essence, a way of accessing the data of the supplier in question without having to go through the GUI. You write a bit of code and get returns from this, from which you can automate and process data. Although it can be long-winded, and you have to go through several hoops to be accredited for these calls, it’s very much worth it, and from this, you can create scalable applications. If the clinical supplier upgrades, it will still supply you with the API to utilise and help automate processes in the surgery.

NHS Digital, over the last few years, has been building up a catalogue of a specific type of online APIs and have published a catalogue called the API catalogue - NHS Digital. The initial bar to entry is low, so if you want to try something, look here to see if it gives you what you need. At the moment, it’s less on accessing or manipulating patient data and more on Spine services though.

Another place to obtain data around Snomed and BNF to help your automation journey is the Technological Reference Update Distribution or TRUD which is a library which updates regularly with supporting data sources you will find useful. We use this source for my product PatientLeaf. Mark Wardle, who in my eyes is a genius, has also created free wrapper code to help you get easier access to this data via microservices. You can get more information about this from Projects (wardle.org)

Example of Levels of Automation

Automation can take several forms, and for the purposes of understanding this, it’s good to break it down into 3 main types.

Robotic Automation is where you need to automate the same or very similar repetitive task.
Intelligent Automation uses algorithms to define paths to desired endpoints.
Artificial Intelligence uses Machine Learning and Neural Networks to try to replicate real behaviour as much as possible.

The best way of conceptualising this is to put it into the context of an example: A receptionist facilitating patients in a flu clinic.

I hold my flu clinics in my surgery on Saturdays now as access is easier for patients, and I can do my vaccines en mass during this time. We ask for a receptionist to help receive patients. We have no separate appointments for those over 65s and under 65s; we just book them and then give them the appropriate vaccine on the day. When the receptionist receives the patient, we have a sticker which she asks the patient to put on if they are under 65, and it’s not easy to tell, so if they are obviously under 65 no need for a sticker. I then know to give these patients the Cell-based vaccine. So how could we automate this with the parameters of the 3 levels above such that I don’t need a receptionist in future clinics?

This is a flow diagram of the processes involved.

**Patient and Data Flows of a Flu Clinic**

So let’s go through each of the above examples in detail and how I would approach each one with automation in mind. Please bear in mind we are only trying to replace this section but it’s important to know the overall flow.

Robotic Automation

Looking at the above, we need a way of identifying the patient and putting down that they have arrived.

Identifying the Patient
We need input from the patient via a touch screen or keyboard to put down, for example, their date of birth and surname. We then need to look this patient up in the surgery database.

Via an API, we’d query the patient database with the inputs to return the said patient or inform the patient that they cannot be found and try again (this is the same as current surgery self-booking applications).
Without an API, you’d need to create an internal database of patient demographics from a Clinical System Export to Excel and then query this.
You could not do this via a Macro without the patient being given access to the clinical system!

Booking the patient in
Once you have identified the patient you need to put down that they have arrived.

Via an API, there are calls for you to pick the correct clinic and patient then push on the clinical system that they have arrived.
Without the API, your best bet is to create a separate application which sits in the Clinician’s room and manages when a patient has arrived.
You could do this via keystrokes and screen scrapping the clinical system, but your chance of error would be high!

As robotic automation just does a task with no “intelligence” you’d have to rely on the clinician to decide which type of vaccine to give.

Intelligent Automation

There is a grey area here around the cross-over between robotic and intelligent automation, but the key message is as you plug more decision processing into the flow, the more you enter the realm of intelligent automation.

In the example above, when identifying the patient, the application would create a simple algorithm.

If the patient is under 65 but above 40, display a screen message to ask the patient to pick up the sticky at the reception desk and put it on and hope they follow instructions!

The clinician would then know that this patient needs the under 65 jab.

Intelligent Automation can get really complex, and some of the current online consultations use complex decision trees, which are absolute (ie a question has yes, no or option answers) in triaging patients via online methods, like a form of pseudo-AI.

Artificial Intelligence

This is where it gets really complex and relies heavily on probability and statistical analysis via Machine Learning and Neural Networks. We are far away from this at the moment, but it’s an incredibly exciting field to be in currently.

In the context of the above example, to implement an AI solution, we need the following.

A Camera
Photographs of all our patients

When the patient enters the surgery, the camera would use AI for facial recognition to identify the patient and “if the GP would have difficulty identifying if they were under 65”.

You’d need two neural networks, one to identify the patient and the second would be if they are under 65 but look close to or over 65, ie if they need a sticker. AI is a field I’d like to look into in the future and beyond the scope of this blog. It also just goes to show you how complex a receptionist’s job is. I also find it interesting that a lot of automation is focused on replacing receptionists, who you could argue are the most important front end of the surgery!

In summary, I hope you appreciate how important APIs are now in the automation agenda and complexity ramps up as you move from simple tasks to more complex requirements.

Splitting up General Practice into Botable Chunks

Taking the above surgery workflow in more detail I thought I’d devote this last section into use cases which might be useful to look into if there were to be further efficiencies in primary care. It just goes into a bit more details around areas in general practice which might have scope for automation in the future. This list is not exhaustive but hopefully is a good start on areas which are of interest to you.

Summary

Robot Process Automation in General Practice is a good way of conceptualising problems and breaking these problems down into processes which we can then digitise with the endpoint of improving efficiencies which is a real focus within the NHS currently. I’m so pleased that this has finally received focus from the NHS as to me it is a very important area of using useful tech to improve the way we run our practices.