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 Workflows 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
Copyright
c
2019 by SCITEPRESS – Science and Technology Publications, Lda. All rights reserved
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 Workflows 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 Workflows 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 Workflows 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. 707713, 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. 3549, 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. 539549, 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. 291304, 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. 518523.
C. Pagliari, D. Detmer, and P. Singleton, “Potential of
electronic personal health records,” BMJ, vol. 335, no.
7615, pp. 330333, 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. 521531, 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. 75105, 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