Process Deep Dive #3 - GP Referrals into Kainos Evolve

This next set of blogs will walk through the processes at a high-level sharing example of code, discussing key decision points and challenges encountered along the way.

1.1 - Accessing Electronic Referral System

The first stage is to start up the web browser and log in to the Electronic Referral System (ERS) using the virtual smartcard (VSC).

The VSC is assigned to a nominated active directory account and uses the four-digit pin code stored within the encrypted credentials vault.

It is important to remember that the assigned robot can only access the four-digit pin. The pin code is masked out to prevent any bot developers seeing what it is. Only the ERS process may use this smart card, and role-based access strictly enforced.

The bot then selects the filter options to list patient referrals. The filter criteria can be set up to filtered by speciality, clinician or location. To allow the process to be self-managing, I decided to select ALL for all the options to list all referrals. This allows the virtual smartcard permissions to govern which referrals are shown.

The advantage of this approach enables another speciality to be added just by granting access to the virtual smartcard. No bot reprogramming or adjustments are necessary.

1.2 - Filtering Patient Referrals

You will notice how the bot is told to wiggle the mouse. Through the development lifecycle, we discovered peculiarities with the application, which made us apply small fixes like these as well as the odd wait stage. Robotic process automation magnifies application deficiencies and these need to be addressed in the process design.

1.3 - Reconciling Patient Referrals

The Electronic Referral System is a real-time application that dynamically updates. GP Referrals appear in the system at anytime. To avoid the risk of duplicate patient referrals in the work queue, each referral must be checked to see if it is a duplicate and the collection adjusted accordingly.

Best practice guidance talks about the notion of triggers. A trigger is an event that starts a bot process from running.

A trigger could be receipt of a text message, an email or a change of state on a live application.

The biggest challenge for ERS is what element to use as a trigger. The addition of a new referral in ERS is not sufficient. Anyone who uses ERS will know about the print status. It is a flag that can be set to Yes or No. Yes denotes that a referral has been processed either by a bot or a human. During the get data stage, the bot will look for referrals (UBRN) with a printed status of NO.

The final action for this stage is load all referrals and key clinical data into a queue ready for processing.

1.4 - Loading Items into the Queue

The next blog in this series will look at the retrieval of patient data from ERS and the downloading of clinical attachments.

#RPA #AI #ERS

All objects and processes for this automation are available for free from the NHS Marketplace.