Clinical Workflows based on OpenEHR using BPM

Tiago Ribeiro, Sérgio Oliveira, Carlos Portela and Manuel Santos

Centro Algoritmi, Universidade do Minho, Portugal

Keywords: Clinical Workflows, Electronic Health Records, OpenEHR, Business Process Modelling.

Abstract: The integration of clinical workflows in electronic health records systems has been problematic due to the

complex nature of clinical processes. For that reason, many health institutions have opted to maintain a few

clinical workflows on paper, which has been compromising the quality and efficiency of several provided

services. The purpose of this study is to investigate if the OpenEHR model can be applied in the

configuration and management of clinical workflows using Business Process Modelling (BPM), with the

focus on clinical forms based on OpenEHR archetypes and having has background the institution Centro

Hospitalar do Porto (CHP). The need to review the workflows is pertinent due to the lack of integration of

clinical workflows on their Electronic Health Records system. To analyse this possibility, a prototype was

created containing: i) a BPM tool to configure and manage the clinical workflows; and ii) a web application

to execute them and call the external clinical forms. The obtained results proved that the use of a BPM tool

to configure clinical workflows allows the interoperability and flexibility of the prototype, which helps to

improve the quality and efficiency of the clinical practice.

1 INTRODUCTION

Nowadays, Electronic Health Records (EHR) are

essential in the health sector. The integration of this

technologies on health institutions instigated a

change on how clinical workflows should be

executed, which was viewed with some distrust by

the health professionals, who saw the clinical

activities performed daily suffering changes

(Kilsdonk et al., 2011).

Sometimes, the workflows of clinical work are

not contemplated on EHR systems, having

consequences like the loss of control by the health

professionals over their patients and the treatments

to be given. These problems can seriously

compromise the efficiency and quality of the

services provided by the health institutions. A lot of

these institutions find it difficult to keep

technologically up to date because of the lack of

financial means to invest on those technological

solutions that could improve their processes (Pearce

and Bainbridge, 2014).

This study aims to address the integration

problems of clinical workflows on EHR, so the

control and quality of the daily tasks performed by

health professionals can be improved. The

investigation’s idea is to understand if it is possible

to apply the OpenEHR model in the configuration

and management of clinical workflows using a

Business Process Modelling tool, with the focus

being on the clinical forms based on OpenEHR

archetypes. To perform the investigation has

described, an Artefact was developed to formalize

the workflows and solve the integration problems

found and the problems brought by the absence of

the workflows.

This paper is organized in 6 sections. Section 1

introduces the work context; Section 2 presents the

background and related work. Section 3 presents the

Research Methodology used in this study. Section 4

describes how the Prototype was developed. Section

5 presents the obtained results. Finally, Section 6

discusses the findings and concludes with some

guidelines for future work.

2 BACKGROUND AND RELATED

WORK

2.1 Clinical Workflow

Clinical workflows are defined as being a set of

steps of clinical processes, that involves multiple

people, for example, health professionals and

352

Ribeiro, T., Oliveira, S., Portela, C. and Santos, M.

Clinical Workﬂows based on OpenEHR using BPM.

DOI: 10.5220/0007878203520358

In Proceedings of the 5th International Conference on Information and Communication Technologies for Ageing Well and e-Health (ICT4AWE 2019), pages 352-358

ISBN: 978-989-758-368-1

patients, and it’s expected they consume, produce,

transform or exchange information (Militello et al.,

2014). The clinical workflow is also defined as the

allocation of multiple tasks performed by one or

many clinicians in the healthcare processes and the

way those clinics collaborate. We can separate them

into four categories: first the clinical tasks

structuring; second the tasks performance

coordination; third allow the information flow to

support the task performance and finally the fourth

category, monitoring tasks performance (Niazkhani

et al., 2009).

2.2 Business Process Modelling

BPM has been defined as a set of principles,

methods and tools to manage business processes

with the main goal of improve them (Dumas et al.,

2013).

The BPM life cycle is presented in Figure1. It starts

identifying the process, where the boundaries,

processes relationship and prioritizing are studied.

The process discovery phase focus on understanding

the business process model As-is. Next, the process

analysis includes a set of techniques which allows

the process performance analysis. This analysis will

enable the identification and evaluation of

improvements to the process, which will lead to the

To-be model. After implementing the To-be model,

it’s necessary to develop mechanisms and

techniques for monitoring and control to assess if the

process is fulfilling the defined performance goals

(Dumas et al., 2013).

2.3 Electronic Health Records

An EHR system is defined as a repository of patient

information, stored in electronic format. This

information can be exchanged, if the proper security

mechanisms are secured so only authorised users can

access and view it. The main purpose of EHR is to

support the continuous, efficient and qualitative

integration of healthcare (Häyrinen et al., 2008).

The storage of information, relevant to business

processes, by healthcare institutions in electronic

format, allows the application of a set of data mining

techniques. This application can enable the finding

of related patterns to adverse events, mistakes and

unnecessary costs hidden in the clinical processes

structure. Thus, this analysis can allow the

identification of bad performance causes and allow

managers to take action to optimize the identified

processes (Ruffolo et al., 2007).

Figure 1: BPM Life Cycle (Dumas et al., 2013).

EHR systems are often perceived as having a lot of

potential to significantly improve clinical and

administrative services quality in healthcare

institutions. This improvement happens because an

EHR system eases patient monitoring and allows

patients to have more control and responsibility in

their treatments and care (Pagliari et al., 2007).

2.4 OpenEHR

The use of the OpenEHR approach allows for the

structuring, management, storage and commutation

of patient data in a secure and reliable way between

different health organizations. The main idea behind

this approach is to standardize health related

concepts used in databases or EHR systems in a set

of libraries, denominated archetypes (Buck et al.,

2009).

2.5 Related Work

The work developed by (Yao and Kumar, 2013) had

the main goal of demonstrate how the design of

flexible clinical processes, with the formalization of

clinical knowledge in rules and the contextualization

of information details, in a way that clinical

workflows with multiple participants can improve

healthcare quality.

To verify the objective of the investigation, a

Prototype was created. This Prototype allowed the

design and execution of clinical workflows, to prove

its flexibility on clinical practice. The BPM tool

chosen was Drools-Flow 5.2 and the notation to

design the workflows used was BPMN 2.0 (Yao and

Kumar, 2013).

Clinical Workﬂows based on OpenEHR using BPM

353

The results obtained by (Yao and Kumar, 2013),

allowed demonstrating that the new approaches of

designing flexible and adaptable clinical workflows

can bring some benefits to the medical community,

like reducing the incidence of treatment mistakes,

which improves patient safety. Other benefits

described are the faster and better recommendations

in many decision points, which allow the

improvement of services provided in health

institutions.

3 RESEARCH METHODOLOGY

The research methodology used in this investigation

was the Design Science Research (DSR)

Methodology for Information Systems. To (Hevner

et al., 2004), this methodology requires the creation

of an innovative and relevant artefact to approach a

certain problem and the evaluation of the artefact is

essential to check its relevance for the problem

being studied. A Process Model for DSR was made

by (Vaishnavi and Kuechler, 2008) which is based in

five steps: Awareness of Problem, Suggestion,

Development, Evaluation and Conclusion.

The Awareness of Problem must produce an output

with the proposal for the identified problem. In this

investigation, the identified problem is the lack of

integration of certain clinical workflows in the EHR

system, which can compromise the efficiency and

quality of the provided services in CHP.

In the Suggestion phase, the objectives and

functionalities of the investigation must be defined,

accordingly with the existing literature. In this

investigation, the suggestion defined to approach the

problem was the development of a Prototype than

can integrate a BPM tool in a web application. The

BPM tool will allow configuring and managing the

workflows, while the web application will run them.

On the Development phase, the defined Suggestion

is developed and implemented. In this investigation,

the Prototype was developed, after defining its

requirements.

The Evaluation phase is performed after the

Development phase, so the Prototype can be

evaluated accordingly with the defined criteria. In

this phase, the utility, quality and efficiency of the

Prototype is also evaluated. In the context of this

investigation, the Prototype is evaluated based on

the defined requirements and if it fulfilled them.

In the last phase, Conclusion, the investigation

results are analysed and interpreted. In this

investigation, the developed Prototype was validated

with members that are developing the EHR system

on CHP, so they could draw conclusions about its

utility to suppress the integration problems found.

4 PROTOTYPE DEVELOPMENT

This section contains the relevant information

related with the development of the Prototype.

Initially, a list of requirements defined is presented,

followed by the BPM tool chosen for the Prototype.

Next, we present the Architecture developed for the

Prototype, its functionalities and, finally Sequence

Diagrams that represent messages exchanged

between systems.

4.1 Requirements

The Prototype was built with the goal of developing

a solution that solves the lack of the workflow’s

integration and the problems generated by that

absence.

The following requirements where defined for the

referred Prototype:

• Use of a free BPM tool;

• BPM tool should allow the configuration of

clinical workflows;

• The tool chosen must allow workflows to be

executed in external application, to secure the

Prototype interoperability;

• The BPM tool should allow the integration with

external databases;

• The Prototype must allow the integration of

OpenEHR based clinical forms;

• The Prototype needs to be flexible, so the

configurations made in the workflows using the

BPM tool are reflected on the web application

developed to execute them;

• The Prototype must secure the user access to the

web application;

• The Prototype should allow the users to visualize

the information about the workflows they

worked on.

4.2 BPM Tool

The BPM tool chosen to configure and manage the

clinical workflows was the ProcessMaker.

This tool offers a free version which fitted the

defined requirements perfectly fine, not imposing

boundaries in any of the main functionalities. But,

the main reason for this choice is related with the

documentation provided by the platform for their

API. The amount of information made available,

ICT4AWE 2019 - 5th International Conference on Information and Communication Technologies for Ageing Well and e-Health

354

really facilitated the tool’s use and the understanding

of the API use and handling.

The API provided by ProcessMaker is built in PHP.

It enables the remote access to ProcessMaker

through external scripts and the access to many

endpoints provided by the platform. These endpoints

allow the actions that can be performed inside

ProcessMaker can also be done remotely. The BPM

tool also has the functionality of allowing the

connection with external databases, one of the

requirements of the Prototype.

4.3 Architecture

The Architecture designed for the Prototype can be

viewed Figure 2. The user, in the context of this

Prototype can be a Health Professional or a Patient,

can start a clinical workflow. To begin the process,

the user chooses the workflow that he intends to

execute, and the decision is routed to the BackEnd,

responsible to consume the ProcessMaker’s API to

create an instance of the selected workflow and

receive the initial form. The BackEnd handles the

information received, in JSON format, and interacts

with the FrontEnd to present the form to the user.

This interaction is recurring, until the decisions

made by the user dictate the end of the workflow or

the next form is assigned to another user. On some

scenarios, the relevance of data leads to the need to

insert it in a database (DB) that simulates an existing

in an EHR system. In this case, the BackEnd will

interact with ProcessMaker API and the DB.

Sometimes, it’s necessary for the BPM tool to

communicate directly with the DB, to receive

essential information for the continuity of the

workflow execution. This communication is made

by triggers, an object than can be created in

ProcessMaker.

One of the main requirements of the Prototype, was

to guarantee its flexibility. This means the

configurations and changes made to the workflows

present on ProcessMaker need to be reflected during

their execution on the web application. This

requirement allows for the modifications to be

quicker and accessible, otherwise when a change

needed to be made, the base code would need to be

altered. The current Architecture allows the

fulfilment of this requirement, because the execution

of the workflows is made with calls to the API, task

by task, which means the workflow version being

executed it is always the most recent one.

Figure 2: Prototype Architecture.

4.4 Functionalities

The following functionalities were developed for the

web application.

• Structure to enable the communication with

ProcessMaker;

• Login structure. The users are validated

accordingly with the users configured on

ProcessMaker;

• Allow the users to see the following Case lists:

“Inbox”, “Draft” and “Participated”;

• Users can create new Cases of workflows, when

the first task is assigned to that user. They can

also answer Cases when they are routed to a task

they are assigned;

• Execute workflows on the web application;

• Structure to route users to forms based on

OpenEHR archetypes;

• The only variables send to ProcessMaker are the

ones needed to execute the workflow;

• Allows the creation and storage of document

with information related to the workflows

concluded.

These functionalities were developed having in mind

the requirements defined for the Prototype.

4.5 Sequence Diagrams

To ease the understanding of the developed

functionalities, Sequence Diagrams were created to

demonstrate the exchange of messages between the

different systems of the Prototype. The language

used to model the Sequence Diagrams was UML.

Access Application

The Sequence Diagram related to how the users can

access the application can be viewed in the Figure 3.

The process starts when a user inputs the

authentication information in the Login interface.

This information is validated by ProcessMaker, to

check if the user exists in the platform. If it returns

the user does not exist, then an “Invalid data”

message is shown, otherwise ProcessMaker returns a

token needed to consume its API. The token and

Clinical Workﬂows based on OpenEHR using BPM

355

username are stored in the web application in

Cookies.

If the authenticated user is a Health Professional,

then an API request is made to receive the Case list

associated to him and the user is forwarded to the

interface Case List. When the user is a Patient, then

he can select the workflow he wants to start and is

forwarded to the Initial Form of the selected

workflow.

Figure 3: Sequence Diagram “Access Application”.

Start Case

In the Figure 4, it is possible to visualize the

Sequence Diagram that demonstrates how a user can

start a case.

This sequence begins when a user selects a Case to

be started. When this happens a request is made to

ProcessMaker’s API to start a Case in the BPM tool,

sending Process and Task identifier. If the request

succeeds, ProcessMaker creates an instance of the

selected workflow and returns the Case identifier,

the “url” for the form assigned to the initial Task and

the variables the BPM tool needs to give continuity

to the workflow execution. This information

received, allows the web application to route the

user to the initial form of the selected Case and,

consequently, start the execution of the workflow

associated to the Case.

Figure 4: Sequence Diagram “Start Case”.

Execute Workflow

The Sequence Diagram related to how the

workflows are executed in the web application can

be observed in the Figure 5.

The user fills the form and submits the information

he inserted. When the user presses the submit

button, a request is made to ProcessMaker’s API,

which includes the Case and user identifier and

variables filled in the form that ProcessMaker needs

to continue to execute the workflow. The BPM tool

returns the information of the next Task in the

workflow, to understand if the user assigned to the

next Task is the same that is authenticated in the

web application. If this is the case, then a request is

made to the API to receive the information on the

next form and forward the user to it, otherwise the

user returns to the List Cases interface and workflow

is paused until the user which the next Task is

assigned continues the workflow.

Figure 5: Sequence Diagram “Execute Workflow”.

5 RESULTS

In this section, first there will be an explication of

the clinical workflow implemented on this study and

executed in the web application created for the

Prototype. Next, an evaluation of the defined

requirements is made, explaining how they were

resolved in the developed Prototype.

5.1 Clinical Workflow Implemented

The implemented workflow, to test the developed

Prototype, was the representation of a computed

tomography (CT) exam request. The graphic

representation was created using BPMN 2.0 notation

and can be viewed in the Figure 6.

The workflow can be started by a health professional

when he intends to request a CT exam. An initial

form is presented, so the health professional can

insert the patient identifier. When that form is

submitted, a connection is made between

ProcessMaker and the DB to check if the patient

exists in the system, then another verification is

made to check if the patient has records of previous

exams performed. When this verification also

returns true, then the health professional is routed to

a form where he/she can check the list of exams the

patient performed, deciding if they are enough or if

there is the need for the CT exam. If he decides the

exams presented are enough for the evaluation, then

the workflow ends, otherwise it is routed for the

“Check variables” form. When any of the previous

verifications returns negative, if the patient does not

ICT4AWE 2019 - 5th International Conference on Information and Communication Technologies for Ageing Well and e-Health

356

exist or the DB does not have exam records of him,

then the workflow is redirected directly to the

“Check variables” form. On this form, the health

professional will be presented with the patient

information, like weight, age or if it has a

pacemaker, if the patient exists, otherwise he will

have to fill this information. If the health

professional, after analysing the patient information,

thinks he/she cannot perform the exam, then the

workflow ends, otherwise it is routed for the

technician, which is the element responsible for

performing the CT exam.

Once the workflow is routed to the technician, he

makes the decision to perform or not the exam.

When he refuses to perform it, he must fill the

reason of refusal and the workflow will end, sending

an email to the health professional with the

justification. If he accepts to perform the exam, then

the workflow is routed to the “Publish Results”

form, which is assigned to the health professional. In

this last phase of the workflow, the health

professional will fill the medical comment of the CT

exam result, publish the results on the BD and end

the workflow.

Figure 6: Workflow “CT Exam Request”.

5.2 Requirements Evaluation

Use of a free BPM tool: The BPM tool chosen,

ProcessMaker, has a community version which is

free to use. The functionalities available in this

version were more than enough for what the

Prototype needed.

BPM tool should allow the configuration of clinical

workflows: ProcessMaker allowed the design of

workflows, using the BPMN 2.0 notation. The

design includes the configuration of the workflows

created in the platform.

Secure Prototype interoperability with external

applications: The Prototype interoperability allows

the communication between ProcessMaker, where

the workflows are managed and configured, and the

web application, where the workflows are executed.

The interoperability between these two systems was

possible due to the web application consuming the

available ProcessMaker API with REST requests to

their endpoints.

The BPM tool should allow the integration with

external databases: In certain scenarios, it is

necessary for the BPM tool to communicate with

databases to check or manipulate the information. In

the workflow implemented in this study, it was

necessary to check in the DB if the patient existed

and if he had any records of exams. To secure this

requirement, ProcessMaker contains an object that

allows communicating with external databases. To

create that object, the user only needs to insert the

connection information of the DB and check if the

connection is successful.

The Prototype must allow the integration of

OpenEHR based clinical forms: This requirement is

needed to allow the web application to connect the

user with the clinical forms based in OpenEHR

archetypes. In each Task of the workflow in the

ProcessMaker, we can create forms and link

variables to them. For each form, there is a variable

called “linkToForm” that contains the url for the

external form based on OpenEHR archetypes. The

web application receives that variable and routes the

user to the url.

The Prototype needs to be flexible: In clinical

environments, there is a constant mutation of the

clinical processes. Taking this into account, it is only

natural that the Prototype developed allows for the

modifications in the clinical workflows on

ProcessMaker to be reflected in their execution in

the web application. The explanation how this

requirement is fulfilled is directly related with the

interoperability. The web application, while

executing the workflow, receives the information

task by task, so when a change is made on the

workflow design, then it is always reflected when

executing in the web application.

The Prototype must secure the users access to the

web application: ProcessMaker allows the

configuration of users that can have access to the

platform and be assigned to tasks in the workflows.

To secure this requirement, a login form was created

for the web application and if the authentication

information inserted by the users matches with a

user that is configured in ProcessMaker, then he will

be allowed to enter the platform, otherwise a error

will be displayed.

The Prototype should allow the users to visualize the

information about the workflows they worked on:

When a health professional authenticates in the

Clinical Workﬂows based on OpenEHR using BPM

357

platform, he has access to the list of Cases that can

be started by him, the Cases he needs to respond and

the ones he participated in. On the last one, when the

Case status is concluded, the health professional can

download a document that contains all the

information about the workflow decisions.

With the evaluation of the Prototype requirements, it

is possible to conclude that the defined requirements

were fulfilled.

6 CONCLUSIONS AND FUTURE

WORK

This investigation and, consequently, the Prototype

developed proved useful to understand how BPM

can be applied to clinical workflows based on

OpenEHR. The developed solution allows the

configuration of the clinical workflows using a BPM

tool and demonstrates the importance of BPM in

securing the interoperability and flexibility of those

workflows and their integration with external

applications.

The main limitation of this study was the use of a

free BPM tool, ProcessMaker. Although all

functionalities could be built and ProcessMaker

didn’t restrict the development of the Prototype, the

usage of a tool more centralized on healthcare would

facilitate the development phase.

The Prototype developed is the main contribution of

this work. We present a solution that is capable of

configure and manage the clinical workflows based

on OpenEHR and a web application that can execute

them, while communicating with the BPM tool and

reflecting the changes made to the workflows. This

formalization of the workflows can lead to

efficiency improvements and, consequently, an

increase in the quality of the services provided, due

to the decision and clinical practice standardization.

As for future work, it is necessary to extend the

Prototype application to other workflows and

identify its functional consistency to better guarantee

it is a solution to the problems found in CHP related

to the lack of integration of certain clinical

workflows. It is also important to make sure the

Prototype is presented and explained to Health

Professionals, so they can understand the benefits a

solution like this can bring to clinical practices and

its performance.

ACKNOWLEDGEMENTS

This work has been supported by FCT – Fundação

para a Ciência e Tecnologia within the Project

Scope: UID/CEC/00319/2019.

REFERENCES

E. Kilsdonk, L. W. P. Peute, S. L. Knijnenburg, and M. W.

M. Jaspers, “Factors known to influence acceptance of

clinical decision support systems,” in Studies in

Health Technology and Informatics, 2011.

C. Pearce and M. Bainbridge, “A personally controlled

electronic health record for Australia,” J. Am. Med.

Informatics Assoc., vol. 21, no. 4, pp. 707–713, 2014.

L. G. Militello et al., “Sources of variation in primary care

clinical workflow: Implications for the design of

cognitive support,” Health Informatics J., vol. 20, no.

1, pp. 35–49, 2014.

Z. Niazkhani, H. Pirnejad, M. Berg, and J. Aarts, “The

Impact of Computerized Provider Order Entry

Systems on Inpatient Clinical Workflow: A Literature

Review,” J. Am. Med. Informatics Assoc., vol. 16, no.

4, pp. 539–549, 2009.

M. Dumas, M. La Rosa, J. Mendling, and H. A. Reijers,

Fundamentals of Business Process Management. 2013.

K. Häyrinen, K. Saranto, and P. Nykänen, “Definition,

structure, content, use and impacts of electronic health

records: A review of the research literature,”

International Journal of Medical Informatics, vol. 77,

no. 5. pp. 291–304, 2008.

M. Ruffolo, M. Manna, V. Cozza, and R. Ursino,

“Semantic clinical process management,” in

Proceedings - IEEE Symposium on Computer-Based

Medical Systems, 2007, pp. 518–523.

C. Pagliari, D. Detmer, and P. Singleton, “Potential of

electronic personal health records,” BMJ, vol. 335, no.

7615, pp. 330–333, 2007.

J. Buck, S. Garde, C. D. Kohl, and P. Knaup-Gregori,

“Towards a compre-hensive electronic patient record

to support an innovative individual care concept for

premature infants using the openEHR approach,” Int.

J. Med. Inform., vol. 78, no. 8, pp. 521–531, 2009.

W. Yao and A. Kumar, “CONFlexFlow: Integrating

Flexible clinical path-ways into clinical decision

support systems using context and rules,” Decis.

Support Syst., 2013.

A. R. Hevner, S. T. March, J. Park, and S. Ram, “Design

Science in Infor-mation Systems Research,” MIS Q.,

vol. 28, no. 1, pp. 75–105, 2004.

V. Vaishnavi and B. Kuechler, “Design Science Research

in Information Systems,” Ais, p. 45, 2008.

ICT4AWE 2019 - 5th International Conference on Information and Communication Technologies for Ageing Well and e-Health

358