DCCSS

A Meta-model for Dynamic Clinical Checklist Support Systems

Shan Nan

1,4

, Pieter Van Gorp

, Hendrikus H. M. Korsten

2,1

, Uzay Kaymak

, Richard Vdovjak

Xudong Lu

and Huilong Duan

School of Industrial Engineering and Innovation Science,

Eindhoven University of Technology, Eindhoven, The Netherlands

Department of Aneasthiaology and Intensive-Care, Catharina Ziekenhuis Eindhoven, Eindhoven, The Netherlands

Philips Research, Eindhoven, The Netherlands

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 workﬂows. Unfortunately, the form deﬁnitions, database queries and workﬂow

deﬁnitions 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 deﬁnitions 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 workﬂow 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 signiﬁcantly (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

workﬂow and (2) they can take into account patient-

speciﬁc 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 workﬂow and patient-speciﬁc 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 deﬁnitions. Secondly, it is unclear how the

checklist deﬁnitions relate to other clinical software

components. For example, it is unclear how hard

coded checklists should be integrated with the clin-

ical workﬂow deﬁnitions 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 speciﬁc

purpose and are difﬁcult 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

 2015 SCITEPRESS (Science and Technology Publications, Lda.)

port the modeling of computerized checklists, which

are aligned with clinical workﬂows and which take

into account patient-speciﬁc context?” While this re-

search question was not tackled by other studies yet,

arber et al., 2007) have already contributed partial

results which we have reused in our study. While

arber et al., 2007) have already demonstrated the

meaningful use of parallel tasks for the modeling of

checklist-supported workﬂows, 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 workﬂow

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-

ﬁt 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

ﬂexibility 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 conﬁrm 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 conﬁrmed

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

ﬁnishes 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 conﬁrm 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

workﬂow, the clinical rule, interoperability between

workﬂow and rule, as well as the layout. We conclude

the modeling requirements in four items as follow.

Clinical Workﬂow. The dynamic checklist model

should support clinical workﬂow 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 Workﬂow and Rule.

The dynamic checklist model should have the

ability to deﬁne of relationship between clinical

workﬂow 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 speciﬁc 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 workﬂow, 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

deﬁned 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 Deﬁnition Lan-

guage (XPDL) and Yet Another Workﬂow 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 deﬁnitions be-

tween different workﬂow 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 workﬂow 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 efﬁcient, rational, stan-

dardized, intuitive and ﬂexible 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

speciﬁcation of an action in these formats. Personal-

ized criteria are modeled as situations to make each

checklist (item) speciﬁc 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-

ﬁcult 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 difﬁcult 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 workﬂow 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 workﬂow, the rule, the

layout and the mapping between workﬂow and rule.

In this section, we present the meta-model concern-

ing these four aspects.

3.1 Clinical Workﬂow

In previous section, we analyzed business process

Figure 1: Workﬂow.

modeling languages and conclude BPMN as the most

suitable one for modeling clinical checklist related

processes. Our clinical workﬂow 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 workﬂow engine.

As shown in Figure 1, the meta-model of clinical

workﬂow abstracts the clinical workﬂow 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. Speciﬁcally,

there are three kinds of ﬂow 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 speciﬁc

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 predeﬁned Cri-

terions. Action step stands for the actions reﬂect 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 ﬁrst 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 workﬂow 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 workﬂow and clinical rules

can interact. The interaction between clinical work-

ﬂow 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-

ﬂow when necessary.

We abstract these requirements in the meta-model

shown in Figure 4. Here we deﬁne 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 deﬁned

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 workﬂow 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

ﬁrstly 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 Workﬂow.

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 ﬁve 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 speciﬁc 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 speciﬁc 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 workﬂow

elements should link with checklists. We use an XML

Figure 6: Clinical Rule Example.

Figure 7: XML Example.

ﬁle 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 deﬁne 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 deﬁned 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 workﬂow engine is designed

to support the workﬂow model. In this part we in-

terfaced with BizAgi Express business management

system’s APIs

. 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 workﬂow 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

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 ﬁeld of checklist modeling.

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 speciﬁc 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 difﬁcult 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-

ciﬁc 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 deﬁnition

language. Additionally, ad-hoc checklists (e.g., the

aforementioned resuscitation checklist) can also ben-

eﬁt 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 beneﬁts from the underlin-

ing data model in GLIF, which is based on the Ref-

erence Information Model. One limitation is that the

workﬂow engine cannot beneﬁt 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 workﬂow models only

use limited amount of data (which can be handled

with code supplements to the DCCSS model). How-

ever, deﬁning 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 workﬂow, the clinical rule, the lay-

out and the interoperability between the workﬂow

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-

ciﬁc constructs which were not yet supported by the

more general BPMN and GLIF metamodels, we have

ensured that DCCSS meets checklist-speciﬁc 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 speciﬁc workﬂow engine or rule engine product.

This is important since hospitals already have a vari-

ety of process aware information systems (which con-

tain workﬂow 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 signiﬁcant 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. Artiﬁcial intelligence in medicine, 31(1):1–27.

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) Speciﬁcation 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