DCCSS
A Meta-model for Dynamic Clinical Checklist Support Systems
Shan Nan
1,4
, Pieter Van Gorp
1
, Hendrikus H. M. Korsten
2,1
, Uzay Kaymak
1
, Richard Vdovjak
3
,
Xudong Lu
4
and Huilong Duan
4
1
School of Industrial Engineering and Innovation Science,
Eindhoven University of Technology, Eindhoven, The Netherlands
2
Department of Aneasthiaology and Intensive-Care, Catharina Ziekenhuis Eindhoven, Eindhoven, The Netherlands
3
Philips Research, Eindhoven, The Netherlands
4
School of Biomedical Engineering and Instrumental Science, Zhejiang University, Zhejiang, China
Keywords:
Checklist, Meta-model, Process, Rule, BPMN, GLIF.
Abstract:
Clinical safety checklists receive much research attention since they can reduce medical errors and improve
patient safety. Computerized checklist support systems are also being developed actively. Such systems
should individualize checklists based on information from the patient’s medical record while also considering
the context of the clinical workflows. Unfortunately, the form definitions, database queries and workflow
definitions related to dynamic checklists are too often hard-coded in the source code of the support systems.
This increases the cognitive effort for the clinical stakeholders in the design process, it complicates the sharing
of dynamic checklist definitions as well as the interoperability with other information systems. In this paper,
we address these issues by contributing the DCCSS meta-model which enables the model-based development
of dynamic checklist support systems. DCCSS was designed as an incremental extension of standard meta-
models, which enables the reuse of generic model editors in a novel setting. In particular, DCCSS integrates
the Business Process Model and Notation (BPMN) and the Guideline Interchange Format (GLIF), which
represent best of breed languages for clinical workflow modeling and clinical rule modeling respectively. We
also demonstrate one of the use cases where DCCSS has already been applied in a clinical setting.
1 INTRODUCTION
Safety checklists have been published by clinical so-
cieties in recent years with the purpose of reducing
medical errors and improving patient safety. Well es-
tablished clinical studies indicate these checklists can
improve the quality of care significantly (Babayan,
2011). To motivate the routine use of checklists,
various checklist support systems have been devel-
oped (Avrunin et al., 2012). Among these systems,
computerized systems are considered as the most
promising ones as (1) they can be integrated with clin-
ical information systems and embedded in the clinical
workflow and (2) they can take into account patient-
specific context information. Yet, a major obstacle of
implementing checklist in computerized support sys-
tems is the additional efforts on encoding checklist
into the systems, especially making them adaptive to
clinical workflow and patient-specific context infor-
mation.
Currently, computerized checklists are typically
encoded directly in the source code of software sys-
tems. This is undesirable, especially since such an en-
coding can be realized in multiple ways. This causes
two problems. First of all, ad-hoc encodings in source
code increase the time to understand and update the
checklist definitions. Secondly, it is unclear how the
checklist definitions relate to other clinical software
components. For example, it is unclear how hard
coded checklists should be integrated with the clin-
ical workflow definitions which are supported by a
hospital information system, or with the clinical rules
which are supported by clinical decision support sys-
tems. Another limitation is that hard coded com-
puterized checklists are only developed for a specific
purpose and are difficult to be reused in one hospi-
tal or shared among hospitals. This maps to our pri-
mary research question: “Which meta-model can sup-
272
Nan S., Van Gorp P., H. M. Korsten H., Kaymak U., Vdovjak R., Lu X. and Duan H..
DCCSS - A Meta-model for Dynamic Clinical Checklist Support Systems.
DOI: 10.5220/0005241902720279
In Proceedings of the 3rd International Conference on Model-Driven Engineering and Software Development (MODELSWARD-2015), pages 272-279
ISBN: 978-989-758-083-3
Copyright
c
2015 SCITEPRESS (Science and Technology Publications, Lda.)
port the modeling of computerized checklists, which
are aligned with clinical workflows and which take
into account patient-specific context?” While this re-
search question was not tackled by other studies yet,
(F
¨
arber et al., 2007) have already contributed partial
results which we have reused in our study. While
(F
¨
arber et al., 2007) have already demonstrated the
meaningful use of parallel tasks for the modeling of
checklist-supported workflows, it was not yet inves-
tigated how to deal for example with dynamicity in
checklist forms. Also, unlike the results from this pa-
per, previous studies did not yet contribute a meta-
model which supports interoperability with workflow
management and decision support systems.
Checklists are usually adopted from clinical
guidelines and clinical pathways (Weiser et al., 2010).
Representation formats of executable clinical guide-
lines and clinical pathways have been studied for
decades (De Clercq et al., 2004). Efforts have been
made on formalizing, executing and standardizing
clinical processes and clinical rules. Industry stan-
dards have been developed out of these efforts (Ko
et al., 2009). These standards have also been ap-
plied to clinical pathway modeling before (Scheuer-
lein et al., 2012). It would be ideal if dynamic check-
lists support system developments could also bene-
fit from these methodologies. This maps to our sec-
ondary research question: “How can we reuse exist-
ing modeling languages for the modeling of dynamic
checklist support systems?”
The outline of this paper is as follows. Section 2
analyzes the modeling requirements by demonstrat-
ing an envisioned use case of our clinical partner.
The requirements are used to assess existing model-
ing languages for clinical processes as well as guide-
lines. Section 3 derives DCCSS from the require-
ments. Section 4 demonstrates how DCCSS can be
applied to the use case from Section 2. Section 5
compares the differences between our approach and
related works. Section 6 elaborates on the support for
flexibility in healthcare processes (since BPMN has
been critized in this context). Finally, Section 7 con-
cludes the paper.
2 BACKGROUND
In this section, we illustrate an envisioned applica-
tion of checklist to clarify functionality requirements
of the checklist model. Then we conclude the mod-
eling requirements for checklist from the envisioned
application. Finally, we discuss the criteria of select-
ing business process modeling languages and clinical
rule languages for checklist representation.
2.1 Envisioned Application of Checklist
For a better understanding of how a checklist can be
used in clinical setting, we describe an envisioned ap-
plication in a peri-operative period. Lots of efforts on
improving quality of care in the peri-operative period
by using checklists have been proposed and validated.
Researchers have designed checklists for both routine
procedures and emergencies in the operating room.
We choose a use case derived from clinical prac-
tice to indicate how the checklist can be applied. A
patient John Doe is planned for a coronary artery by-
pass graft (CABG) surgery. Before the operation,
a nurse takes his blood for lab tests. The results
show that he has a high international normalized ratio
(INR), which indicates that he may excessively bleed
during the surgery. Then, checklists are sent to the
responsible surgeon, anesthesiologist and nurse. The
abnormal INR value has been highlighted in the anes-
thesiologist’s checklist as a warning item. Only after
these three person confirm every critical items for the
operation, the process can continue. At the time the
operation is about to start, the operation team stands
together to perform a time-out checklist. The oper-
ation starts after the time-out checklist is confirmed
and signed. During the operation, unfortunately, a
cardiac arrest happens. The operation team is un-
der stress as the patient is in danger and warnings are
blinking on every monitor. In this situation, they fol-
low a resuscitation checklist, which prioritizes things
and guides them out of danger. After the operation
finishes successfully, the patient is sent to the inten-
sive care unit (ICU). There, an intensivist and an ICU
nurse need to know what happens before and during
the operation. Checklists are distributed to these two
person to help them to confirm critical patient infor-
mation. At the same time, they can know from a pic-
ture log who did what in which phase. So that if any-
thing goes wrong, they know whom to ask.
2.2 Modeling Requirements
From the envisioned approach, we derive a set of re-
quirements capturing the need of representing clinical
checklist knowledge comprehensively. There are four
modeling components mapping with these four key
aspects in checklist application, which are the clinical
workflow, the clinical rule, interoperability between
workflow and rule, as well as the layout. We conclude
the modeling requirements in four items as follow.
Clinical Workflow. The dynamic checklist model
should support clinical workflow which can be in
sequential, parallel or conditional orders and in-
teroperable with other systems.
DCCSS-AMeta-modelforDynamicClinicalChecklistSupportSystems
273
Clinical Rule. The dynamic checklist model should
support both simple situational-action rule (SAR)
and nested rules, i.e. one rule can be used as the
action of another rule.
Layout. The dynamic checklist model should sup-
port customized layout which facilitates priority
for emergency cases.
Interoperability between Workflow and Rule.
The dynamic checklist model should have the
ability to define of relationship between clinical
workflow and clinical rule.
2.3 Analysis of Existing Modeling
Languages
The requirements mentioned previously are partly
supported in other mature modeling approaches.
These approaches have been used both in the health-
care domain and other industries. For example, clin-
ical pathway management systems are increasingly
used in recent years in hospitals. These systems are
designed to assign tasks to the right person at the right
time. Computerized provider order entry (CPOE) sys-
tems can use rules regarding specific patient context
like their age, gender and renal function to prevent
medical errors. More intelligent guideline based clin-
ical decision support systems use complex clinical
rules to help doctors making decisions (De Clercq
et al., 2004).
The representing formats used in these systems
can be divided into two categories by their design
purpose and application domain. One category con-
sists of business process modeling languages, which
focuses on describing activities, roles, resources and
their relationships in complex business processes.
The other category consists of guideline model-
ing languages which focus on the decomposition of
guideline tasks into more detailed clinical decision
support rules. The two categories facilitate two as-
pects of checklist respectively. It would be ideal if we
can combine these two formats together.
Business process modeling languages are in-
tended to allow designers to formalize a process def-
inition such as a workflow, in which it can represent
in which order activities are carried out and who will
perform them. Checklist is a group of activities that
should be performed at the proper time by the proper
person. Thus checklists have been encoded in such
formats. A care path behind a group of checklists are
defined as a process. In the process, each checklist
is modeled as an activity. An activity is allocated to
a role who has a certain function in the whole pro-
cess. These activities have orders between each other.
The simplest order is sequential, which means two ac-
tivities are performed one by one. To represent this,
the concept transition has been used. More complex
orders like branching in parallel or conditionally are
also supported. In these cases, the concept gateway
is used to represent the split and merge of several
branches. Most business process modeling tools have
graphical model editor to make modeling work eas-
ier. Some provide human task user interface design-
ers. Standards from industry have been made to make
human tasks sharable between different systems (OA-
SIS, 2012).
Among business process modeling languages,
some languages gain more attention from industry
and academia, namely Business Process Execution
Language (BPEL), Business Process Modeling and
Notation (BPMN), XML Process Definition Lan-
guage (XPDL) and Yet Another Workflow Language
(YAWL) (Ko et al., 2009). BPEL is developed for
specifying actions within business processes with web
services. BPEL uses eXtensible Markup Language
(XML) as its representing format which is under-
standable by IT expert but not domain expert. As
an industry standard, BPEL is widely supported in
business process management systems. XPDL is de-
signed to interchange business process definitions be-
tween different workflow products. It is also writ-
ten in XML but it has a graphical notation which
makes it understandable to domain experts. However,
XPDL is designed for interchanging rather than exe-
cuting. YAWL is an academic language that was de-
signed through a rigorous analysis of workflow pat-
terns. YAWL has graphical notations as well. Differ-
ent from other industry-driven languages, YAWL is
less supported in commercial business process man-
agement systems. BPMN is a standard that offers the
most expressive and understandable language at the
time of writing. The standard also prescribes an inter-
change format that enables the combination of mod-
eling software and runtime execution software from
different industry vendors (OMG, 2011). The BPMN
language was designed to be comprehensible by both
IT specialists and professionals. Various other au-
thors treat BPMN as a cost efficient, rational, stan-
dardized, intuitive and flexible instrument for mod-
eling healthcare processes (Scheuerlein et al., 2012).
We conclude the advantages and drawbacks of these
languages in Table 1.
While business process modeling communities
are developing business process modeling languages,
the health informatics community has taken a dis-
tinctive approach which is more stressed on decision-
making issues. Clinical rules are the main concern of
these efforts. In one piece of rule, situation and action
MODELSWARD2015-3rdInternationalConferenceonModel-DrivenEngineeringandSoftwareDevelopment
274
Table 1: Comparison between process modeling languages.
IT Expert Domain Expert Visualization Support Systems Extensibility
BPEL + - - + +
BPMN + ++ + + +
XPDL + + + - -
YAWL + + - - -
are two essential components. Situation is a group of
criteria. When this group of criteria is met, an action
will be taken. This action can be to perform a clinical
activity or to evaluate another clinical rule. A check-
list item or even a checklist can be considered as a
specification of an action in these formats. Personal-
ized criteria are modeled as situations to make each
checklist (item) specific to patient context.
Different from business process modeling lan-
guages, clinical guideline modeling languages con-
cerning decision-making are academia-driven. As a
result, these languages are not standardized by inter-
national organizations. It makes these languages dif-
ficult to be interchanged in different systems. One ex-
ception is the Arden Syntax. Arden Syntax has been
accepted as an Health Level 7 (HL 7) and American
National Standards Institute (ANSI) standard. How-
ever, this language has no graphical representation
format. This makes Arden difficult to understand
for domain experts. Another wide-spread language
which takes the advantage of Arden Syntax is Guide-
Line Interchange Format (GLIF) (Peleg et al., 2001).
GLIF is used as the basis of other guideline model-
ing tools (e.g. EON, SAGE) and has been supported
by a commercial rule-based clinical decision support
system, Gaston (De Clercq et al., 2004). Mapping be-
tween GLIF and other clinical guideline languages is
also possible and well studied (Peleg et al., 2001).
Based on our analysis, both BPMN and GLIF have
their own advantage for representing checklist knowl-
edge in their domain. From these two languages, we
derive our clinical workflow metamodel and clinical
rule metamodel respectively.
3 THE DCCSS META-MODEL
From the aforementioned analysis of requirements,
there are four main concerns while modeling the dy-
namic checklist, which are the workflow, the rule, the
layout and the mapping between workflow and rule.
In this section, we present the meta-model concern-
ing these four aspects.
3.1 Clinical Workflow
In previous section, we analyzed business process
Figure 1: Workflow.
modeling languages and conclude BPMN as the most
suitable one for modeling clinical checklist related
processes. Our clinical workflow meta-model is de-
rived from BPMN, with the purpose of taking the ad-
vantage of BPMN and existing business process man-
agement systems as well as their workflow engine.
As shown in Figure 1, the meta-model of clinical
workflow abstracts the clinical workflow aspect of the
checklist. In the root level, there is a Process entity
which stands for a clinical process. Process contains
multiple Flow Elements, which stands for constructs
in the process. These elements can be divided into
two groups. Flow Node is the abstraction of activ-
ities between system and human. Each node has a
participant to specify who is the owner. Specifically,
there are three kinds of flow nodes. Activity stands
for clinical activities that can be performed by human
or computer systems. Event stands for interactions
between current process and other processes or sys-
tems. Gateway is used for representing branching or
merging in the process. A Sequence Flow is the link
between two nodes.
3.2 Clinical Rule
Our clinical rule meta-model is derived from GLIF,
which is widely used in healthcare domain. The meta-
model of clinical rules shown in Figure 2 is the ab-
DCCSS-AMeta-modelforDynamicClinicalChecklistSupportSystems
275
Figure 2: Rule.
stract of situation-action clinical rules that have been
used in clinical processes. In the checklist context, all
the clinical rules aim to perform an action in specific
conditions. This form is very suitable for remainder
decision support system like checklist system.
In this meta-model, we use a Guideline to rep-
resent one clinical rule. Each guideline can have
several GuidelineSteps. These guideline steps can
be divided into four categories, which are Branch-
Step, SynchronizationStep, DecisionStep and Ac-
tionStep. Branch step and synchronization step are
used to represent parallel decisions. Decision step is
used for making decisions based on predefined Cri-
terions. Action step stands for the actions reflect to
decisions. For a checklist item, the action is showing
the content of the item.
3.3 Layout
Checklists is heavily used for intensive care scenarios.
In that setting, it is critical for the users to grasp the
most important information at the first glance on the
checklist. In this sense, layout is an important factor
to these checklists.
We describe the meta-model of checklist layout in
Figure 3. Every element belongs to a Page, which
represents one page of checklist. Every element is
considered as a kind of Control. A control has its
width, height, x coordinate, y coordinate and color.
There are two categories of controls. One is basic el-
ement, which can present text and photo on a page.
The other kind is container, in which other controls
can be nested.
3.4 Checklist
Checklists are presented to users in pages in the cor-
rect context. The clinical workflow meta-model an-
swers the question of where and when the user should
see the checklist. The clinical rules answer the ques-
tion of what exactly the user can read in the checklist.
Figure 3: Layout.
However, there remains an unanswered question re-
garding how the clinical workflow and clinical rules
can interact. The interaction between clinical work-
flow and clinical rules are two-way. On one hand,
clinical rules should only be triggered at the right time
in the whole process. On the other hand, clinical rules
should have the ability to modify the clinical work-
flow when necessary.
We abstract these requirements in the meta-model
shown in Figure 4. Here we define a group of check-
list within one process as a three-layer structure. All
the checklists are associated with a clinical Process.
The process has an id to identify itself and a name
as a description. Each page of checklist that should
be used in certain context is represented as a Sce-
nario. Each scenario has an id and name. Besides
that, the potential owner attribute is used to specify
which user(s) is scheduled to perform the checklist.
The phase attribute is used to describe the stage in
the whole process. In the real clinical settings, it is
possible that people always perform several check-
lists together as a group, although they are defined
separately. Therefore, we design a Group Scenario
to represent this construct. There is a grouped items
attribute in group scenario to indicate which scenar-
ios are in a group. Each scenario can link with several
rules before entering and after submission. These rule
can effect the workflow itself. In each scenario, there
are groups of Tasks which stand for checklist items in
one checklist. The content is represented as descrip-
tion. Moreover, each item is associative with several
rules that can be executed before the assignment and
submission of the item.
4 EXAMPLE
In this section, we demonstrate an example to indi-
cate the applicability of the proposed meta-model. We
firstly describe a model of an example checklist in the
selected format. Then, we discuss a prototype system
based on our meta-model. The system has an inter-
face with an EMR system and it can execute the ex-
MODELSWARD2015-3rdInternationalConferenceonModel-DrivenEngineeringandSoftwareDevelopment
276
Figure 4: Checklist.
Figure 5: Peri-operative Workflow.
ample checklist model effectively.
4.1 A Checklist Model
In this section we model the use case from Section 2.1
utilizing our proposed meta-model.
Firstly we model the clinical process in the BPMN
language (Figure 5). We created five swim lanes in the
BPMN model to represent the ve participants. We
abstracted eight steps which need to perform check-
lists as eight tasks in the model. The pre-operative
checks are done by three roles in parallel. So we use
parallel gateways to represent this kind of relation-
ship.
Then we model checklist items in each checklists
in GLIF (Figure 6). Each checklist is considered as a
guideline in GLIF. Each item in the checklist is con-
sidered as a clinical rule, which should contain at least
an action that indicates the specific task for the user.
Decisions are optional to a rule. If there is no deci-
sion in one item, it means the action will be executed
by default. However, decisions are important if we
want patient context specific items (e.g., checking the
INR rule). In that case, we express that in an GLIF
expression.
After that, we need to indicate how the workflow
elements should link with checklists. We use an XML
Figure 6: Clinical Rule Example.
Figure 7: XML Example.
file to represent these relationships (Figure 7). Every
checklist is nested in the process. The scenario ID at-
tribute is used to identify which checklist in the GLIF
model should be linked.
In the end, we define the layout of the checklist
in HTML 5 format (Figure 8). All the controls are
mapped to HTML 5 types. The relationship between
a checklist and its layout is also defined in the previ-
ously mentioned XML model.
4.2 A System Based on the Meta-model
Tracebook is a prototypical system for executing
DCCSS models (Nan et al., 2014). Based on the
DCCSS structure, Tracebook has four main compo-
nents (in Figure 9). The workflow engine is designed
to support the workflow model. In this part we in-
terfaced with BizAgi Express business management
system’s APIs
1
. The rule engine is used to sup-
port clinical rules. In this part, we interfaced with
Gaston (De Clercq et al., 2004), which is a GLIF
2.0 based clinical rule engine. We implemented the
checklist engine to deal with the interoperability be-
tween the workflow engine and rule engine based on
our mapping model. The checklist engine also send
checklists to the UI renderer in XML format. The UI
renderer uses XSLT to interpret the XML into HTML
5 format and show them to users as checklists. This
system has been implemented and under evaluation in
1
See http://wiki.bizagi.com/.
DCCSS-AMeta-modelforDynamicClinicalChecklistSupportSystems
277
Figure 8: Page Layout.
Figure 9: System Framework.
Catharina hospital in Eindhoven, the Netherlands. It
interfaces with the hospital EMR system.
5 RELATED WORKS
In recent years, other researchers have also con-
tributed to the field of checklist modeling.
F
¨
arber et al. proposed to a method to model
clinical processes, where they propose checklist as
a new type construct in the clinical process model-
ing (F
¨
arber et al., 2007). In their model, they treat ac-
tivities strongly belonging together to one critical ex-
ecution phase and without execution order as a check-
list. Their model mainly focuses on how to simplify
the modeling of clinical processes rather than en-
abling the representation of a clinical checklist. Thus,
that line of work did not yet consider how to model
clinical rules nor how to integrate layout aspects.
Avrunin et al. proposed smart checklists for
human-intensive medical systems (Avrunin et al.,
2012). They use a process modeling language called
Little-JIL. Little-JIL supports task assignment and
complex orderings of tasks. Also, checklist items can
change dynamically during the execution, driven by
changes of the context. There are several differences
between (Avrunin et al., 2012) and our approach.
Firstly, our work creates a general modeling frame-
work for checklists which aim to reuse existing mod-
eling languages, whereas their approach focuses on
utilizing a specific modeling language mainly for clin-
ical process. Secondly, checklist layouts and group-
ings of checklists were not yet considered by Avrunin
et al.
6 DISCUSSION
Healthcare processes are normally highly dynamic
and ad-hoc. The order of activities might be changed
during the execution according to patient status.
Some activities can be removed or added during the
execution. These dynamic features are difficult to be
represented in procedure process models. Case han-
dling or case management is proposed to represent
the dynamicity. Instead of activities or routines, case
handling focuses on the concept case, which is spe-
cific to a certain context. Case Management Model-
ing and Notation (CMMN) is proposed to standardize
the case handling model (OMG, 2014). Different with
BPMN, CMMN takes a declarative approach rather
than a procedural approach. CMMN aims to repre-
sent what activities a person can do, whereas BPMN
aims to represent how activities should be performed
by a person.
The CMMN can be more representative in de-
scribing care-givers’ behavior as they normally do.
However, we argue that the use of checklist is to stan-
dardize practitioners’ behavior at the very moment,
rather than enable them doing critical thing in ad-hoc
To standardize the behavior, a procedural description
is more clear and easy to build. It is also important to
show the status of the whole process to users in the run
time. This meets the design target of BPMN. There-
fore, we have chosen BPMN as our process definition
language. Additionally, ad-hoc checklists (e.g., the
aforementioned resuscitation checklist) can also ben-
efit from the event handling mechanisms in BPMN.
Data aspects are also important to make clinical
decision support systems portable to different health-
care organizations using heterogeneous data source.
Currently, our approach benefits from the underlin-
ing data model in GLIF, which is based on the Ref-
erence Information Model. One limitation is that the
workflow engine cannot benefit from this data model
yet. This is not preventing us from performing initial
MODELSWARD2015-3rdInternationalConferenceonModel-DrivenEngineeringandSoftwareDevelopment
278
clinical evaluations since our workflow models only
use limited amount of data (which can be handled
with code supplements to the DCCSS model). How-
ever, defining an explicit and independent data model
which is sharable between all the four DCCSS aspects
is an important line of ongoing work.
7 CONCLUSION
In this paper, we propose DCCSS as a meta-model
for dynamic checklist, which reuses existing infras-
tructure from outside the clinical domain. By analyz-
ing a use case derived from clinical practice, we sum-
marize four checklist modeling requirements, which
are the clinical workflow, the clinical rule, the lay-
out and the interoperability between the workflow
and the rule. According to these modeling require-
ments, we have reviewed the popular business process
modeling languages and clinical rule modeling lan-
guages and we have chosen BPMN and GLIF as the
best building blocks for DCCSS. By then adding spe-
cific constructs which were not yet supported by the
more general BPMN and GLIF metamodels, we have
ensured that DCCSS meets checklist-specific model-
ing requirements. Finally, we have modeled a peri-
operative checklist to demonstrate the effectiveness of
the meta-model. The DCCSS model can be executed
on a prototypical system Tracebook which can inter-
face the EMR system of our clinical partner.
One advantage of our approach is that it gives
a platform independent model which is not tied to
a specific workflow engine or rule engine product.
This is important since hospitals already have a vari-
ety of process aware information systems (which con-
tain workflow engines) and decision support systems
(which have rule engines). When using small wrap-
per systems such as Tracebook, hospitals can easily
reuse their existing products and knowledge for real-
izing dynamic checklist functionality. When the hos-
pital legacy systems lack support for standards then
the integration work will still be significant but the ef-
forts of building a standard interface on top of a pro-
prietary legacy system are orthogonal to building dy-
namic checklist support on top of that.
In ongoing work, we are extending DCCSS with
support for platform independent data access from
each of its four perspectives.
REFERENCES
Avrunin, G. S., Clarke, L. a., Osterweil, L. J., Goldman,
J. M., and Rausch, T. (2012). Smart checklists for
human-intensive medical systems. In IEEE/IFIP In-
ternational Conference on Dependable Systems and
Networks Workshops (DSN 2012), pages 1–6.
Babayan, R. K. (2011). Effect of a comprehensive surgical
safety system on patient outcomes. The Journal of
urology, 185(4):1329–30.
De Clercq, P. a., Blom, J. a., Korsten, H. H. M., and Has-
man, A. (2004). Approaches for creating computer-
interpretable guidelines that facilitate decision sup-
port. Artificial intelligence in medicine, 31(1):1–27.
F
¨
arber, M., Jablonski, S., and Schneider, T. (2007). A com-
prehensive modeling language for clinical processes.
In European Conference on eHealth 2007, GI, Old-
enburg, Germany. Lecture Notes in Informatics (LNI),
pages 77–88.
Ko, R., Lee, S., and Lee, E. (2009). Business process man-
agement (BPM) standards: a survey. Business Process
Management Journal, 15(5):744–791.
Nan, S., Van Gorp, P., Korsten, H., Vdovjak, R., Kaymak,
U., Lu, X., and Duan, H. (2014). Tracebook: A dy-
namic checklist support system. In Computer-Based
Medical Systems (CBMS), 2014 IEEE 27th Interna-
tional Symposium on, pages 48–51.
OASIS (2012). Web Services Human Task (WS-
HumanTask) Specification Version 1.1. [on-
line] Available at: http://docs.oasis-open.org/
bpel4people/ws-humantask-1.1.html. [Accessed 09
September 2014].
OMG (2011). BUSINESS PROCESS MODEL AND NO-
TATION (BPMN). [online] Available at: http://
www.omg.org/cgi-bin/doc?dtc/10-06-04.pdf. [Ac-
cessed 09 September 2014].
OMG (2014). Case Management Model and Nota-
tion. [online] Available at: http://www.omg.org/spec/
CMMN/1.0/PDF/. [Accessed 09-September-2014.
Peleg, M., Boxwala, A. A., Bernstam, E., Tu, S., Greenes,
R. A., and Shortliffe, E. H. (2001). Sharable repre-
sentation of clinical guidelines in glif: relationship to
the arden syntax. Journal of biomedical informatics,
34(3):170–181.
Scheuerlein, H., Rauchfuss, F., Dittmar, Y., Molle, R.,
Lehmann, T., Pienkos, N., and Settmacher, U. (2012).
New methods for clinical pathwaysbusiness process
modeling notation (bpmn) and tangible business pro-
cess modeling (t. bpm). Langenbeck’s Archives of
Surgery, 397(5):755–761.
Weiser, T. G., Haynes, A. B., Lashoher, A., Dziekan, G.,
Boorman, D. J., Berry, W. R., and Gawande, A. a.
(2010). Perspectives in quality: designing the WHO
Surgical Safety Checklist. International journal for
quality in health care, 22(5):365–70.
DCCSS-AMeta-modelforDynamicClinicalChecklistSupportSystems
279