The importance of Workflow in eClinical

This article talks about workflow. It was previously published as a Linkedin Article in 2022.

Intro

I will be returning to Part 2 of my topic of EDC systems and their role in Decentralised Clinical Trials in my next post. In the meantime, I want to raise something that I believe makes a platform. Process automation, also referred to as Workflow. This might be a harder read than usual, but give it a chance, I think it is important.

Part 1 – Internal versus External Workflow

Imagine the world of database systems for clinical trials before workflow.

A patient completes their eConsent form with the entry of their electronic signature. The form sits in a database until a report is run. When the report is run, it indicates that the investigator is due to counter sign the form. Someone runs the report and then chases the Investigator.

Of course we could just as well be talking about a Monitoring report, an SAE or an eCRF to be reviewed. Without workflow, we haven’t moved very far from piles of paper. Time is lost.

Most eConsent solutions provide application logic so that when an eConsent form is prepared, the form definition indicates who signs and in which order. That is not workflow per-se, it is meta information that is used to drive the logic of the application. This is ok, but of course, it is built once, used once. Other similar logic might be hard coded in many other places.

Fully configurable workflow takes things to the next level where the fact that the form is presented to the patient, that they complete it, that they then sign it and that the investigator is sent a notification and they need to counter sign it are all sequenced in a series of commands – typically a workflow syntax. This processing of this syntax typically manifests as tasks and objects to users. An object might be the presentation of a document – like an eConsent form. The tasks manifest as activities that a user (or users that are assigned to a role) can see and action.

External Workflow.

A number of years ago, I was responsible for the IBM Clinical Trial Management System (CTMS) – Clinware. Functionally it was similar to the CTMS products we see today. Towards the end of the development cycle I became unhappy with the results. The bulk of users spent a considerable amount of time telling the system that things had happened. Virtually all of the activities were External to the system.

Of course, exceptions occurred, even back then. I wrote the (nasty) code that read the EDC data into the CTMS system in order to automate some of the ‘actuals’ information. In this way, when a patient was created, or, patient visit was initialised, it automatically appeared in the CTMS. It was a dog though as it depended on matching metadata between the EDC and CTMS systems. The wrong site code, wrong visit id etc and the data transfer halted. The root cause of failure was separate metadata between EDC and CTMS. Take away that separation and things are a lot easier – Veeva have done a moderately better job here.

The majority of workflow solutions in clinical trials today are what I would refer to as external workflow systems. Activities are performed externally and someone needs to inform the workflow system that the activity was completed. This is the same in 2022 as it was in 1998, but things are starting to change.

Internal Workflow

Internal Workflow is different. It is connected to the activity being performed. Let me give you the eConsent problem above with internal workflow applied. My example here is from Clinpal, but the principles can apply to any workflow based solution.

We have a patient eConsent workflow that has been designed for a particular trial. The workflow starts automatically when the patient is created. It immediately creates a task (with associated message/push) to the patient asking them to open and complete the eConsent. The workflow is sitting at Pending. [Note: this example is for a remote consent, for site based consent, the task would be directed to the site personnel role(s)]

Next step, the patient receives the task, reads it and presses a button to open the eConsent form. [Note: we would also see reminder management here]

This button press transitions the workflow to Opened. The task to the patient changes from ‘Please complete…’ , to ‘Please Continue…’.

Next, the patient proceeds through the eConsent. In this eConsent we have a Quiz that is completed as soon as the patient has confirm each block of information. When the quiz starts, the workflow transitions to ‘Quiz Started’. On successful completion of the Quiz, the workflow transitions to Pending Patient Signature. The task to the patient also corresponding switches to ‘Can you now please electronically sign the eConsent form’.

As you will notice from the steps above, the actual workflow transitions are driven by the action of the user. As actions occur, the database is updated to log when the action occurred as well as driving the activities for the following action. Tasks and Messages to the user (or role) are also transitioned ensuring each stakeholder has up to date process instructions to follow.

This internal workflow reduces lag, reduces manual effort in communicating actions by each party and tracks progress automatically. From a trial management perspective, the ‘actuals’ are truly actuals as they reflect what is actually occurring as opposed to retrospectively reflecting what happened.

With only limited exceptions, workflow systems in clinical research are limited to CTMS, or have been implemented as point / silo solutions independently. They are rarely effectively implemented for EDC or in DCT solutions. I see that changing with DCT Platforms.

Part 2 – SOPS and their relationship with Workflow

Changing gear a bit now. I would like to compare Workflow Definitions with Standard Operating Procedures.

A good Standard Operating Procedure (or Work Instruction) provides the following;

• Pre-requisites (or process input)
• The activity to perform
• Who should perform the activity – ideally a Role
• What the output of the activity is
• What is next

An internal workflow definition is largely the same as the above. i.e.

Workflow == Processes

Of course, not all activities take place inside a computer system. Processes define manual as well as digital activities. However, electronic workflow is an ideal place to structure not just the automated digital activities, but also the manual activities. When defining a good Project Plan, it is very useful in understanding the process steps that define the tasks and order that activities will take.

Project plans and CTMS system task lists have virtually no relationship to the SOPs that are designed to describe the processes being followed.

So, question – when we define activities that are undertaken in a digital environment, should we write SOPs and Workflow processes independently?

The Future of clinical trial systems and quality management

I believe the solution to the challenging problem of technology in clinical trials lies in the automation of processes (SOPs if you will) with configurable Workflow based systems.

In the past – life was simple. Sponsors and CRO’s wrote SOPs, and their staff followed them. Systems were setup to support this exercise within these organizations. This was not perfect, but it worked.

Now, with new technologies, we have many stakeholders – Participants, Sites, Labs, Safety, etc etc. participating in the lifecycle of a clinical trial, using the same technologies. However, they potentially lack SOPs that reflect the activities that they are being asked to perform by the system configured for the trial. Trial participants for example will never read an SOP, but they do need to follow a process.

For CRO’s and Sponsors, a typical workaround to this problem today is for SOPs to be written in such a generic fashion as to be non specific to any particular approach. I don’t believe that to be an effective solution. Generic processes at best allow an organization to meet audit requirements, but invariably fail to create any business value – in our context – run better trials.

A potential solution is to create systems that build Processes and Workflow at the same time.

This is in the form of instructions to an automated workflow system as well as definitions that can be read and understood by the stakeholders. It is a form of just-in-time process training that mirrors the actual activities that will be asked of the stakeholder. This brings together training, the systems and the processes to ensure each party involved in the lifecycle of the trial is able to carry out their activities in compliance.

Open Workflow Systems

In a perfect world, we have one great do-it-all system with a single workflow engine that interacts across the platform.

In reality, best-of-breed systems will continue to function providing their own external and occasionally internal workflow solutions. Today, we ask users to go to system A, find a list of tasks…. execute these tasks.. and then go to System B, find a list of tasks… execute these tasks etc etc. If you are a site user – I am really sorry.

API’s tend to be used to transfer data between systems. With workflow, APIs may be used to check and confirm workflow states and transitions between systems. Secure open systems that offer workflow support will permit this to occur.

This is key due to the current reality whereby 95%+ of vendors operate with modular technologies with only limited data connectivity. With integrated workflows using API’s, we will see hand-overs occurring without manual interaction.

On a side note – I have been made aware of some vendors that have twigged to the importance of workflow in their end-to-end platform. To solve the problem they have invested in off-the-shelf Business-Process-Automation tools. This will not work. I will explain on a separate thread.

Timeframes

To define when I believe such systems might exist, I need to look back at my own experiences. Personally, I saw the value of workflow automation while I was working on manual process optimization at Medidata. I felt that the processes should be inside the software rather than simply sitting in a Quality Management document. In 2012, I began the development of Clinpal that had internal workflow, as described above as an underlying principle.

In the 7 year period that I work with a workflow based clinical research platform, I can honestly say that ‘configurable workflow’ never featured on any RFP I received. However, I believe that a recognition of the value of process management support that you see in other industries applied at a core level within clinical research systems will emerge. We are already seeing this with companies like Veeva in the Sponsor / Site areas. Enterprise clinical research platforms deliver their scalability and value through process automation. I believe this will be the case with DCT. Let’s see if the vendors.

Thanks

I would like to take this opportunity to give a shout out to @Ben Gill the engineer that worked with us on the Workflow Language & Engine in Clinpal together with the brilliant @Ian Mills, @Giles Cory and the excellent extended development team. Unsung clinical research tech heroes!