=Paper=
{{Paper
|id=Vol-1140/paper5
|storemode=property
|title=Integration of Documentation Task into Medical Treatment Processes in the Hospital
|pdfUrl=https://ceur-ws.org/Vol-1140/paper5.pdf
|volume=Vol-1140
|dblpUrl=https://dblp.org/rec/conf/zeus/HeweltK14
}}
==Integration of Documentation Task into Medical Treatment Processes in the Hospital==
https://ceur-ws.org/Vol-1140/paper5.pdf
Integration of Documentation Task into Medical
Treatment Processes in the Hospital
Marcin Hewelt and Aaron Kunde
Hasso Plattner Institute at the University of Potsdam
{marcin.hewelt, aaron.kunde}@hpi.uni-potsdam.de
Abstract. Medical Guidelines capture medical knowledge how to diag-
nose and treat certain diseases. To some degree they describe patient
data that is required to make treatment decisions. Usually documentation
of medical procedures is carried out as an afterthought and produces
additional workload for doctors and nurses. In this contribution we study
the German guideline for neck pain, translate the guideline into a process
model and identify the tasks of this process where documentation needs
to take place, as well as the required data.
1 Introduction
Documentation processes are an essential part of medical practice in a hospital.
The documented data is used for billing the health insurer, communication
with other health care facilities (e.g. aftercare, rehabilitation), medical research
and evaluation of treatment options. These days the documented data has not
always direct benefit for the current treatment of a patient. Often only data
that appears useful in the short run is captured, neglecting the requirements
of retrospective research. Finally, documentation processes are also error-prone,
the more so the longer the topic to be documented lies in the past. As a result,
documentation of medical procedures is often carried out only as an afterthought.
This leads to additional workload for doctors, nurses and technical staff as well
as redundant activities and media breaks. A study performed by the Deutsches
Krankenhausinstitut e.V. (DKI) found for example, that surgeons spend 2 hours
for patient-centric documentation and another 42 minutes for administrative
documentation a day. Internists spend more than 2,5 hours for patient-centric
and 40 minutes for administrative documentation a day ([6], [1]). Administrative
documentation has been defined in this study as necessary data and documents
for communicating with insurance or other administrative offices. Patient-centric
documentation on the other hand contains all documents having the patient in
focus, like diagnosis and treatment. If documentation were better integrated with
the treatment process, data produced during treatment could automatically be
captured for documentation and the error rate as well as the overhead could
be reduced. This way doctors and nurses would have more time for patients.
In addition, if documentation of the current treatment had direct benefit for
patients and medical staff during the treatment, the motivation to document
would be higher.
N. Herzberg, M. Kunze (eds.): Proceedings of the 6th Central European Workshop on Services and
their Composition (ZEUS 2014), Potsdam, Germany, 27-03-2014, published at http://ceur-ws.org
28 Marcin Hewelt and Aaron Kunde
Our idea is to use a formal model of the treatment process, which can be
executed by a process engine. This way process guidance to the practitioner could
be provided, e.g. making recommendations about the next possible treatment
steps. To make an appropriate recommendation, the system needs certain infor-
mation, based on data, which has been documented before. This information
contains the state of the process, together with all necessary information about
the patient and the environment to support the decision. Our approach is to
log all the necessary information, which has lead to the decision together with
the decision itself as documentation of the process. Therefore we need a formal
model of healthcare processes.
The literature points at many contributions that represent a Clinical Practice
Guideline (CPG) in a way usable by IT systems called a Computer Interpretable
Guideline (CIG). Our idea is to first express the quite simple German CPG for
neck pain with a Business Process Model and Notation (BPMN) model. Since
medical treatment processes can be seen as workflows, standard process modeling
languages, like BPMN [4], should be suitable to represent actual processes in
a hospital as well as CPGs. Most industries employ BPMN to model processes.
Even if BPMN has the same acceptence problems among healthcare professionals
like other proposed formalisms, it is understood and widely accepted in other
professions, e.g. by management and knowledge engineers. Hence other modelling
experts can help healthcare professionals with modelling a CPG more easily.
If a CPG can be represented with BPMN it can be executed by common
process engines, which are already used and established for business processes
like billing and accounting. This supports the integration of CPG models in
existing environments. The integrated CPG models can be used to verify existing
processes or to build a Decision Support System (DSS) for treatment.
As a second step we annotate those activities in the process model which
produce information that is to be documented. This is expressed via the BPMN
construct of a data object. We simply list the information we are interested in
documenting on the arc between the task that produces them and the data object.
According to the Business Process Modeling (BPM) life cycle the process model
has to be configured by attaching additional technical details in order to make it
executable by a process engine. It is also during this step that the decision made
at gateways are to be specified in detail.
This way, the necessary data for each executable task is specified. The data
which is needed for each decision is specified as well and therefore known by
the execution engine. All this data is then logged as process documentation.
Furthermore, this data can be used for consistency checking in the model: Each
task can check, if the data it needs is specified by some task before by building
the reverse reachability graph.
2 Background
A CPG represents evidence-based medical best practices for certain medical
conditions, e.g. lymphoma, describing their diagnosis and treatment. The def-
Integrated Documentation in Medical Treatment Processes 29
inition and importance of CPGs have been mentioned in [10]. Grimshaw and
Russell analysed almost 60 published evaluations of CPG usage and found that a
great majority reported a significant improvement of quality of care and patient
outcome [3]. To ensure the quality of those recommendations, in Germany CPGs
are reviewed and staged in a systematic way by the Arbeitsgemeinschaft der
Wissenschaftlichen Medizinischen Fachgesellschaften (AWMF). In this system the
stage “S3” describes the highest quality. Although CPGs have a certain logical
structure, they consist of free-form text, tables, and diagrams. Many of them are
presented in a long and a short form. The short form may consist of only one or
two pages, describing the overall procedure in a flow-chart. On the other hand,
the long version may contain up to more than hundred pages describing each
step in detail with possible side effects.
Since CPGs are normal text-based documents, they can not be used directly
in computer systems. To do so, CPGs have to be formalized into computer-
interpretable representations, so-called CIGs. There are many examples of CIGs,
which have all been designed by different institutions with different goals in mind.
Wang et al. [10] analyze 11 CIG languages to identify the most important
components. They found that actions and decisions are essential in all analyzed
languages. Additional important components are patient state and execution state.
All of the analyzed languages support this components. Peleg et al. [8] use the
term Task Network Model (TNM) to describe CIGs that support hierarchical
decomposition over time. This ability is an important feature during the modeling
process, enabling a top-down approach and modularization. To find similarities
and differences of languages that are based on TNMs, six languages are compared
in [8]. Despite the fact, that each language has been developed with a different
goal in mind, common components, like structuring treatment plans sequentially,
which may be parallel or not, have been identified. According to this research
exisiting CIGs share most of the features, however, the CIG language landscape
seems very fragmented and lacks a standard.
Mulyar et al. [5] investigate the support of four TNM-based CIG languages
for 43 common workflow patterns like Multichoice, Milestone or Recursion 1 . They
conclude that of all workflow patterns only up to 22 patterns have been supported
by one of the investigated languages (PROforma). On the other hand not much
flexibility has been added by the CIG languages. This leads to the question, if
those specialized CIG languages are really necessary, or if CPGs can be modeled
with a general modeling language, like BPMN [4], which is a freely available
standard by the International Organization for Standardization (ISO).
A current review [7] discusses and classifies 21 articles about research on
CIGs. The classification describes 8 topics of interest for CIG research. These
topics describe constitute phases in the life cycle of a CIG, like the integration
with Electronical Health Record (EHR), validation or exception handling. The
paper gives a good overview of the literature of the past 20 years and it becomes
clear, that the development and deployment of a CIG is not trivial.
1
from http://workflowpatterns.com
30 Marcin Hewelt and Aaron Kunde
3 Conceptual Model
Essentially, guidelines are process models that contain medical knowledge. BPMN
is a widely accepted and understood standard to model business processes.
Because it allows to represent all the relevant concepts of CPGs identified in [10]
and [7], BPMN seems also suitable to model and represent CPGs. A CPG modeled
with BPMN could be integrated into IT systems that are already employed in the
hospital to support administrative workflows. Since BPMN is an open standard,
sharing of guideline models would be easier. Additionally, there are many tools
for validating and transforming BPMN-models available.
To demonstrate our approach, we took the neck pain guideline created by
Deutsche Gesellschaft für Allgemeinmedizin und Familienmedizin (DEGAM)2
[2] (80 pages of narrative, two flow diagrams) and constructed an initial model
in BPMN. This model in figure 1 shows a conceptual top-down view, based on
the flow-chart from the guideline. We used the tasks from the original document
and added necessary decision gates. Additionally the gates were annotated with
the dataflow necessary for documentation.
Our goal is to use as few constructs as possible to map the necessary concepts
from the medical domain. The fewer constructs a model involves, the clearer and
easier to understand it is. In the following we propose a mapping from common
CIG constructs, which were developed to capture concepts of medical CPGs.
Action An action is a simple task. BPMN has the notion of atomic tasks, which
can be executed by the process engine. Each action can be connected to a
data object in which data is stored, like an EHR. The user only has to specify
which data shall be stored in which system We do not want to concern the
user with details on how the data is stored.This has to be done by configuring
the process engine.
Decision Decisions are made by medical experts. They regard the diagnosis to
be made or the treatment to be chosen. This decisions are based on the actual
patient state as represented in one or more data objects providing an EHR.
A DSS might calculate ranked recommendations based on the documented
data in the EHR and present it to the practitioner. The practitioner then
can choose one of those options (or something completely different). Her
choice is then documented in the EHR, together with an optional argument
for the decision. Process models in BPMN use the construct of gateways
which comes in different variants to represent choices to be taken during
the process execution. For decisions we take XOR-Gateways to represent
exclusive decisions.
Data inquiry Data inquiry for actions is implicit in the model. The inquired
data for decisions is for now modeled using textual annotations at the
gateways.
Hierarchical plans Sub-processes in BPMN support the hierarchical decompo-
sition of processes. This construct therefore allows to decompose the model,
an operation also possible in TNMs.
2
http://leitlinien.degam.de/index.php?id=269
Integrated Documentation in Medical Treatment Processes 31
Parallel tasks BPMN supports parallelism using parallel gateways (AND-
Gateways). Those can be used to model parallel tasks, like requesting multiple
tests in the laboratory.
Fig. 1: BPMN process model of neck pain guideline
Scenario Neck Pain Guideline
Our model has one start event (“patient arrives”) and two possible end events
(“patient treated” and “patient referred”). They represent the entry of patients
and the two different outcomes specified in the guideline.
The action “anamnesis” is modeled as an atomic task. During “anamnesis”
the doctor asks the patient about her medical history and current condition,
e.g. where the pain is located and when it began. This information needs to
be documented. The documentation system is modeled as a data object called
“EHR”. The user input is implicit in the BPMN and does not need to be modeled
explicitly. The output for the process documentation has to be modeled, but only
to the point, that the user has to specify, which data has to be documented. This
specification is done by writing the data fields on the edges, which are associated
with the data object. In our example it is shown, that some data called “patient
status”, “pain location”, “pain duration” and more is stored in the data object.
The tasks “clinical examination” and “referral to specialist” also store data in this
32 Marcin Hewelt and Aaron Kunde
data object. An additional data object “discharge letter” is created in the task
“referral to specialist”. Only atomic tasks can have an association to a data object.
Sub-processes like “further examinations” are not connected to data objects so
as not to overload the model. Instead, if a sub-process contains atomic tasks,
which consume or produce data, this is modeled in the sub-process. Because data
objects are referenced by name, a sub-process can use the same data store (e.g.
data object “EHR”) as the overall process, just by using the same name.
Several kinds of decisions are included in our example. The first one is the
most complex. Based on the data stored in the “EHR”, a ranking is presented
which gives the user to classify the patients pain either as “unspecific” or as
“suspicion of serious reasons”. This is modeled for now using a textual annotation.
During the configuration phase of the process model an algorithm needs to be
provided by the process implementer that realizes the decision. The best option
would be to devise a generic decision algorithm and a domain-specific language
for modeling decisions (required data, possible options, arguments for options)
which expressions could be interpreted by the algorithm. This use of user-specified
annotation languages is supported by the BPMN 2.0 standard. However, this
is out of scope for this contribution. The second kind of decision is shown after
the task “further examinations”. The doctor can decide, if she should refer the
patient to a specialist directly or perform X-Ray diagnostics before.
4 Discussion
The hospital process domain exhibits a gap between medical treatment and
organizational processes. While CPGs provide valuable knowledge to medical
practitioners they are not designed to be supported by IT systems. Therefore
CIGs were introduced as formal representation of CPGs. However, they focus on
medical aspects of the process and cannot be easily integrated with organizational
aspects, like registration of examinations, or billing the health insurer. [5] found
that CIGs do not add flexibility to treatment processes. On the other hand,
BPMN was developed to express these business processes and, together with a
process engine, to support them and integrate existing IT systems. Previous work
by Reijers et al. [9] found out, that workflow management, an approach similar
to BPM, can be successfully used to support medical treatment processes.
In this contribution we only consider the integration of documentation steps
into the treatment process. To this end we used standard BPMN with some
additional annotations at the arcs to model one specific textual CPG. Large
portions of the integration work belong to the configuration phase in the BPM life
cycle, in which detailed specification for the process model is provided, to make
the model executable. This includes binding the data objects, used in the model,
to data storages like EHR, mapping the annotations to information produced by
the corresponding task, and providing the decision rules for gateways.
Integrated Documentation in Medical Treatment Processes 33
We plan to evaluate the open-source process engines Activiti 3 , jBPM4 &
Drools5 , ruote6 , Enhydra Shark7 , camunda8 and Bonita BPM9 to our needs.
Then we will implement the modeled guideline in one of these engines address
the afore-mentioned questions.
References
1. Blum, U., Müller, K.: Dokumentationsaufwand im Ärztlichen Dienst der Kranken-
häuser. das Krankenhaus pp. 544–548 (Jul 2003)
2. DEGAM: Leitline Nackenschmerzen. AWMF (Jun 2009)
3. Grimshaw, J.M., Russell, I.T.: Effect of clinical guidelines on medical practice: a
systematic review of rigorous evaluations. Lancet 342(8883), 1317–1322 (Nov 1993),
PMID: 7901634
4. ISO/IEC: Information technology – object management group business process
model and notation. Tech. Rep. 19510, ISO/IEC (Jul 2013)
5. Mulyar, N., van der Aalst, W.M., Peleg, M.: A pattern-based analysis of clinical
computer-interpretable guideline modeling languages. Journal of the American
Medical Informatics Association 14(6), 781–787 (Nov 2007)
6. Müller, K., Blum, U.: Krankenhausärzte: Enormer Dokumentationsaufwand.
Deutsches Ärzteblatt 23(100), 24 (Jun 2003)
7. Peleg, M.: Computer-interpretable clinical guidelines: A methodological review.
Journal of Biomedical Informatics 46(4), 744–763 (Aug 2013)
8. Peleg, M., Bury, J., Fox, J., Greenes, R.A., Hall, R., Johnson, P.D., Jones, N., Kumar,
A., Miksch, S., Quaglini, S., Seyfang, A., Shortliffe, E.H., Stefanelli, M.: Comparing
computer-interpretable guideline models: A case-study approach. Journal of the
American Medical Informatics Association 10(1), 52–68 (2003)
9. Reijers, H.A., Russell, N., Geer, S.v.d., Krekels, G.A.M.: Workflow for healthcare:
A methodology for realizing flexible medical treatment processes. In: Rinderle-
Ma, S., Sadiq, S., Leymann, F. (eds.) Business Process Management Work-
shops, pp. 593–604. No. 43 in Lecture Notes in Business Information Processing,
Springer Berlin Heidelberg (Jan 2010), http://link.springer.com/chapter/10.
1007/978-3-642-12186-9_57
10. Wang, D., Pelegb, M., Tub, S.W., Boxwalac, A.A., Greenesc, R.A., Patela, V.L.,
Shortliffea, E.H.: Representation primitives, process models and patient data in
computer-interpretable clinical practice guidelines:: A literature review of guideline
representation models. International Journal of Medical Informatics 68(1–3), 59–70
(Dec 2002)
3
http://activiti.org
4
http://www.jboss.org/jbpm
5
http://www.jboss.org/drools
6
http://ruote.rubyforge.org/
7
http://shark.ow2.org/doc/1.0/
8
http://www.camunda.com
9
http://www.bonitasoft.com/