You are on page 1of 11

See

discussions, stats, and author profiles for this publication at: http://www.researchgate.net/publication/283796819

Using Requirement Modeling Framework for developing Online


Business Processes
CONFERENCE PAPER SEPTEMBER 2015

READS

3 AUTHORS, INCLUDING:
Mohammad Alhaj
University of Ottawa
22 PUBLICATIONS 40 CITATIONS
SEE PROFILE

All in-text references underlined in blue are linked to publications on ResearchGate,


letting you access and read them immediately.

Available from: Mohammad Alhaj


Retrieved on: 12 December 2015

Using Requirement Modeling Framework for


developing Online Business Processes
Mohammad Alhaj, Kavya Mallur, Liam Peyton
University of Ottawa
Ottawa, ON, Canada
{malhaj, kmall093, lpeyton} @uottawa.ca

AbstractMany Organizations are using Business Process


Management (BPM) to move their existing paper-based
business processes into online in order to improve the quality
of provided services and reduce the operational costs.
Traditional approaches of BPM focus on implementing the
online business process and neglect validating the
improvement of quality the new process is supposed to achieve
in terms of defined business goals. It is desirable to detect and
anticipate any deficiencies in meeting business goals at the
early stages of business process development where corrective
actions can be more easily made. In this paper, we propose a
Requirement Modeling Framework for developing online
business processes where goal models are used to provide
metrics that will measure the performance of online business
processes as they are being developed. Also it uses scenario
models to describe the behavior of the business process rather
than relying on natural language specifications. This can
ensure that the development of online business processes will
improve quality, by giving early indications of any problems
and also improves the quality of the implementation by
providing well-defined modeled scenarios. We present a health
care case study to demonstrate the framework.
Index TermsBusiness Process Management, Business
Process Modeling, Requirement Modeling, Goal Model,
Health Care.

I. INTRODUCTION
Business Process Management (BPM) is used in many
organizations to move their existing paper-based business
processes into online in order to improve the quality of
provided services and reduce their operational and
maintenance costs. Traditional approaches of the Business
Process Management focus on the implementation of the
online business process and neglect validating the
improvement of quality the new process is supposed to
achieve in terms of defined business goals. It is desirable to
detect and anticipate any deficiencies in meeting business
goals in the early stages of business process development
when corrective actions can be more easily made. However,
the development complexity of such processes coupled with
the aggressive development schedules usually result in

inadequate specification, analysis, modeling and reporting


the compliance of business goals.
In the common architecture of the BPM traditional
approach, the Business Analyst Team initially creates the
Requirement Documents, which are mainly a natural
language description of functional and non-functional
requirements, and scenarios of the business processes. The
requirement documents come in the form of spreadsheets,
forms, text, emails and reports. The Development Team
uses the requirement documents to model and implement
the business processes. The Quality Assurance (QA) Team
validates the developed business processes, using web
application testing tools (such as JUnit, Selenium), with
respect to the specification of the requirement documents.
After each testing iteration, the QA team creates a testing
report which outlines the results of the testing that has
occurred, including any unexpected results. The business
process bugs and errors are then defined in a form of tickets
which are assigned to development team members for
fixing. After a number of testing iterations, the developed
business processes are released into production.
There are two shortcomings for the traditional approach,
first using natural language in describing the requirement
documents causes confusion in the business process
scenarios, lack of clarity, and is subject to differing
interpretations by the developers. Second, we do not know
if the business process is performing well or improving,
since at the development stage, we do not validate or
measure the outcome of the business processes with respect
to defined business goals. To counter the negative pattern
of the traditional approach, we propose a development
framework as an attempt to evaluate the business goal of an
existing business process. This will give designers the
opportunity to evaluate the measures of the business goals
and let them do something about it.
In this paper, we propose a Requirement Modeling
Framework for developing online business processes that
uses goal models to provide metrics for the quantitative
measures of the goal compliance of business processes as
they are developed. Also it uses scenario models to describe
the behavior of the business process rather than relying on
natural language specifications. This will ensure that the

development of online business processes improves the


quality, by giving early indications of any problems and
also improves the quality of the implementation by
providing well-defined modeled scenarios. We present a
health care case study to demonstrate the framework.
With our Business Process Development Framework,
developers can track the metrics of the business goals into
business processes and report them rather than neglecting
them. Using goal modeling and metric reporting of early
business process designs can reduce the risk of
performance-related deficiencies by giving an early warning
of problem
The paper is organized as follows: Section II presents
the background and related work; Section III presents the
proposed approach; Section IV presents the datamodel of
the proposed approach; Section V describes a case study of
the Lung Cancer Intake project; Section VI describes
applying the proposed approach on the Lung Cancer Intake
project; section VII presents the evaluation of the
framework, and section VIII the conclusion and future
work.
II. BACKGROUND AND RELATED WORK
The Business Process Management (BPM) provides the
techniques, methods and tools that support the design,
development, management and analysis of online business
processes that involve humans, organizations, applications,
documents and other information sources [2]. Business
process can be modeled using different modeling notations
and modeling applications. The most popular languages are
the Business Process Modeling Notation (BPMN) [14], a
graphical notation for specifying business processes for
business users, and BPEL, an executable modeling
language of web services [13]. We use IBM BPM
application [9], which supports the BPMN 2.0, to model the
business processes and their underlying service
components.
The User Requirement Notation (URN) [3] is used to
model user requirements in terms of goals and business
scenarios. The goal model is described using the goalrequirement language where actors, goals, softgoals, task,
KPIs are defined. While business scenarios are described
using use case map language.
Online business processes are implemented in a serviceoriented architecture (SOA). SOA is an innovative
architectural approach where software applications are
developed and deployed as a set of reusable services [1]
[7]. The most popular implementation of SOA today is
webservices which allows the systems of different platforms
to communication using SOAP protocol [19].
Different approaches and methodologies have been
followed recently to monitor and validate health care
processes. The definition of clinical indicators (their
characteristics and categories) introduced in [12] which
provides a quantitative basis for quality improvement by
identifying the incidents of care that require serious

investigation. Another opinion in [11] argues that there is a


poor correlation between outcome, generated by the clinical
measures, and quality of the provided care. Using the
outcome as a proxy for quality is a greater problem when
the data are used for some purposes than for others. Process
measures are proposed instead as suitable management tool
for validating and accepting quality of care.
To manage and monitor the business processes of a
cardiac patient flow system, a developed architecture for
event processing applications, is proposed in [15]. The
applications collect stream of events triggered by sensors
allocated in process to infer serious medical events in realtime. Another Care Process Monitoring Application
(CPMA) is described in [4] to collect, correlate and
integrate clinical data from various sources, mainly sensors,
of the care process. The clinical data are then used in
generating a performance report to measure the
performance of a care process with respect to the business
goals.
A prototype of model-based application framework is
proposed in [18] to address process-oriented software
development. The framework supports collecting data,
monitoring and reporting within a managed process at run
time. In [8], an approach standardizes the evaluation of the
process efficiency and quality using a clinical reference
process model and generic KPIs. In [5], a framework is
used to monitor the business processes by integrating the
performance measures produced by the Business Activity
Monitoring (BAM) with the semantic of business process
lifecycle. A three step method for goal-driven analysis of
business process models is proposed in [17] that aims at
eliciting possible improvement directions. In these steps a
goal structure is first defined for the process of interest,
then goals are integrated with process warehouse and finally

Fig. 1. Business Process Development Framework

goal structures are used for process analysis and


improvement. In [6], a set of guidelines are defined that
shows the correlation between the goal modeling and the
business process modeling and how a goal model can be
derived from a business process model
The approach in [16] uses real-time location service
(RTLS) technology within the WiFi environment to track
and monitor the movement of the patients in case of
emergency. While a workflow management system is
described in [10] to integrate the components of the
workflow model with the legacy system for a radiology
process. Later, the same work was updated in [20] by
creating a monitoring dashboard to collect the patient data
from the workflow management system and integrate it with
other information systems in the department.
III. BUSINESS PROCESS DEVELOPMENT
FRAMEWORK
We propose an approach to address the issues listed
above based on best practices for developing and testing of
the business processes as in fig. 1. The Business process

development begins when the Business Analyst Team


creates the Requirement Models and delivers them to both
the Development Team and the QA Team. The requirement
models contain a goal model and a set of scenario models to
define different execution paths of the business process.
The Development Team uses the requirement models to
build the Business Process Model and its underlying
architecture, such as the Service Integration Models and the
Service Components. The Business Process Model is a high
level of the business workflow that describes the sequence
of processes and sub-processes linked by control flows and
controlled by business decisions, iterations and
concurrencies. The Service Integration Model is used to
connect services together to create higher-level processes.
Each service defined in the Service Integration Model is
associated to an underlying Service Component. There are
different types of service components, such as forms,
service library and reports. The Service Components act as
container for the service implementation which is handled
by the Architecture Team and he is responsible for the
supplying, maintaining and supporting the infrastructure of

Fig. 2. Datamodel of proposed Framework.

the enterprise such as Services, Processors, VMs and


Databases.
The Quality Assurance (QA) team then uses a suite of
testing tools to perform service unit testing, web application
interface testing, automate generation of test scripts, test
orchestration of multiple services and multiple users and
create performance reports to validate business
performance against goal model. At the end of each
iteration, the quality assurance portal produces the
performance report which is used to measure the
achievement of business goals and testing report for
functional errors and bugs.

Performance Report at the testing model which is used to


satisfy the Business Goals and sub-Goals at the requirement
model.
The green path shows that Scenarios at the requirement
model are used to model Processes at the business process
model and produce Test Scenarios at the testing model. At
the same time Processes at the business process model are
used to validate the Test Scenarios at the testing model.
Test Scenarios are used to generate the Test Cases. In this
paper, the Test Scenarios and Test Cases in the green path
are not described; we leave it for later paper.

IV. DATAMODEL OF PROPOSED FRAMEWORK

To better describe and understand the problem, we use a


health care case study that has been developed in
collaboration with Ontario hospital to improve the
performance of a Lung Cancer Intake process at a cancer
assessment center by automating the business process and
making the forms available online. The requirement
documents for this case study were initially defined in the
form of word documents, spreadsheets and flowcharts to
describe the flow and functionalities of the process services.
Quality assurance of the online business process was
initially done using a unit test harness, test suites and
manual testing of the user interface.
The IBM BPM tool [9] was used to model, implement,
test and run the business process for Lung Cancer Intake as
in fig. 3. The process begins when a clerk receives and
validates a referral fax based on the following options: a) if
it is a New Patient, he creates a new Medical Record
Number (MRN), b) if it is a Thoracic Referral, he pass it to
the Thoracic Nurse Review. At the Thoracic Nurse Review
process, the nurse updates fax information with the patient
information in the center, and when the patient is admitted,
he or she will be pre-assessed for suspected disease and CT
thorax Status. At the Physician Review process, the
physician then review the assessment and order the needed
tests (such as Biopsy, PFT, PET scan). At the Nurse
Contact process, the nurse calls the patient with a maximum
of three attempts to set an appointment for triage and
Navigation Day (if it is needed). If the patient did not reply
on the phone call, the center sends a letter to the referral
physician. The Pending Result process waits for the
completion of the test results, with a maximum of four days.
Once the tests have been completed, it will move the patient
record to test triage. On triage scheduled appointment date,
the triage nurse describes the diagnosis and the urgency and
set an appointment for consult booking. Finally, the consult
booking is conducted for the next available Surgeon or
Respirologist based on the patient status.
Although existing business process has been moved into
production, we were not able to measure and monitor the
project outcomes and whether the project's goals have been
achieved or not. We summarize our observations regarding
the project's development with the following:

In this section, we introduce the data model of our


proposed framework as an attempt to address the modeling
challenges. The goal of datamodel is to bridge the gap
between the user requirements modeling (represented by the
URN [3]), the business processes modeling (represented by
BPMN2.0 [14]) and testing environment.
Figure 2 describes a datamodel where three regions are
defined with different modeling elements. The Requirement
Model region contains the Business Goal which is a
functional requirement that can be further decomposed. The
Business Goal can be achieved by multiple Tasks with the
ability to be validated by multiple Metrics (measures). A
Task is a representation of a Business Requirement
(Functional and Non-Functional) which can be realized as a
Scenario. A Scenario is a collection of tasks that should be
executed in a certain order and it can be owned by multiple
Actors. At the same time, a Business Requirement can be
represented as a Usecase and managed by different
Business Rules or constraints.
In the Business Process Model region, A Process is a
set of activities which may contain different elements, such
as Sub-processes, Forms, Flags, Roles, ObjectTypes,
Decisions and Service Libraries. A Role must be a member
of a User Group. While a Service Library may contain
multiple Service Interfaces and deployed by many Devices,
such as Servers and VMs.
In the Testing Model region, the Test Plan defines the
Test Architecture, and may contain multiple of Test
Scenarios. The Test Plan is executed by a Test Workbench;
while the Test Workbench contains different types of
testing, such as Unit Testing, Web Interface Testing, Multiuser Role Testing and Service Orchestration Testing. The
Test Workbench also writes to the Test Portal which is used
to produce the Bug list and generate the Performance
Report.
In order to understand the relationship between the
requirement model, business process model and testing
model in our proposed framework, we highlight two
colored paths. The red path shows that, the Business Goals
and sub-Goals at the requirement model are measured using
different Metrics which are linked to different Flags at the
business process model. These Flags are the entries of the

V. CASE STUDY

Fig. 3. The Business Process of Lung Cancer Intake

1.

2.

3.

4.

5.

The requirement documents are described in natural


language, which might cause confusion of business
process scenarios, with various interpretations in
the implementation.
The goal of the project is to improve the
performance of the Lung Cancer Intake process.
However, we do not exactly know how efficiently
the process is performing and are we achieving our
business goals?

The requirement documents do not provide any


clinical metrics or the key performance indicators
(KPIs) to measure the achievement of the business
goals.
The deliverables of the project do not specify any
kind of reporting or dashboard to show the status of
the project.
The unit testing and UI testing used for the existing
project are valid for web applications. Testing
business process requires additional methodologies
and techniques such as an end-to end testing to
verify the orchestration of multiple services for
multiple user tasks and reporting to validate the
performance of the business process.

VI. APPLYING THE PROPOSED APPROACH ON THE


EXISTING PROJECT

In this section, we use the proposed approach described


in section 3 to address our observations regarding the
existing Lung Cancer Intake process. The goal of
automating the business process is to increase the patient
satisfaction for the service provided by the cancer
assessment center. This can be achieved based on different
aspects such as reducing the waiting time for the provided
services, improving the quality of the services and reducing
the deceased cases. For simplicity, we only focus on
reducing the waiting time as in table I.
TABLE I. LUNG CANCER INTAKE GOAL
Soft Goal
Goal
Metrics
Increase Patient Lung Cancer
Satisfaction
Intake
Reduce
the Wait_Time_for_Nurse_Review
waiting time
Wait_Time_for_Physician_Review
Wait_Time_for_Nurse_Contact
Wait_Time_for_Pending_Results
Wait_Time_for_Triage
Wait_Time_for_Consult_Booking

The URN [3] is used to define the requirement models.


URN language is supported by a graphical editor, called
jUCMNav which provides rich graphical formatting
features used to improve the goal and scenario modeling.
One of these features is the coloring scheme which
measures the degree of satisfaction using three main levels
and different shades for values in between: unsatisfied
(red), neutral (yellow), and satisfied (green). The coloring
scheme can be used to measure and monitor the

achievement degree of the business goals.


Figure 4 presents a sample of the goal model of the
Lung Cancer Intake as in table 1. The business soft goal is
"Patient Satisfaction" presented at the top with a
contribution of a "Lung Cancer Intake" project as a goal.
There are eight tasks contribute to the goal and represent
the functional behavior of the business process. The
"Reduce the Waiting Time for the service provided" is also
contribute to the "Lung Cancer Intake" goal and connected

Fig.4. A sample of the goal model of the Lung Cancer Intake

Fig.5. Triage scenario model

to six KPIs which are used to measure the waiting time at


different stages of the Lung Cancer Intake process. A KPI
has an evaluation value that measures the current situation,
which ranges between the target value (green color) and
worst value (red color). The contribution relationship
describes how an element contributes to the other in GRL
model. The contribution impact can be positive or negative
and ranges from (-100 to +100).
As part of the requirement models, Scenario models are
also created, using UCM language, to describe the behavior
of the project processes. As an example, the "Triage"
scenario from the Lung Cancer Intake project is described
in fig. 5. In Triage scenario, the nurse performs initial tests
on the patient and identifies the disease site. She then
decides the kind of consultation is required, the degree of
urgency and the order of the patient's treatments that is
needed.

(c)

The Development Team uses the requirement models to


build the business process model of the Lung Cancer Intake
project. In general, most of the elements of UCM scenario
models are directly mapped into the business process
model, i.e., scenarios are mapped into processes, actors are
mapped into user groups, responsibilities are mapped into
service operations and path directions (Or Fork, And Fork,
Or Join, And Join) are mapped into decisions and
concurrencies. Fig. 6a, 6b and 6c are samples of the
modeled processes, Nurse Contact, Pending Results and
Triage integration.
In order to measure metrics (KPIs) defined in the goal
model, we need to add several flags at specific locations in
the Lung Cancer Intake processes. Flags capture the data in
the business process by reading the start and end time
whenever an event is triggered. In our case the event is
triggered when a nurse or physician open or submit an

Nurse Contact process

(b)

Pending Results process

(a)

Triage process

Fig.6. Samples of process models

. .

online form. For example, the waiting time for triage


depends on two processes: Nurse Contact and Pending
Results. The starting event of the Wait Time for Triage is
triggered when the BPM engine finishes the service
orchestrations of the latest process between the two, i.e.,
Nurse Contact and Pending Results, while the ending event
is triggered when the Triage nurse opens the online triage
form.
IBM BPM tool provides a construct called "Tracking
Groups" (aka Flags) which provide the tracking context for
process metrics across the Business process. As an
example, in order to calculate the Wait Time for Triage
process, three objects of "Tracking Groups" are created and
located at: Triage Start Time, Nurse Contact End Time and
Pending Results End Time.

The time interval of the Wait Time for Triage can be


calculated by subtracting the time stamp of Triage Start
Time with latest time stamps of Nurse Contact End Time
and Pending Results End Time. IBM BPM tool provides a
construct called "Time Interval" with a set of starting points
and end points are defined as in fig. 7. After linking all
metrics in the goal model with the Flags related to the Lung
Cancer Intake process, the development team uses the goal
metrics to build the performance dashboard using BI tool.
The QA team uses the testing campaign first to verify
that the functionalities of the product meet the business
requirement specifications and ensure that the Forms satisfy
the expectation of the end users. The first version of Lung
Cancer Intake project is released after a number of testing
iterations and bug fixings. The released version is exposed

Fig.7. Defining timing interval of Wait_Time_for_Triage using IBM BPM

Fig.8. Performance Report for Lung Cancer Intake project

to specific and limited number of the end users, i.e.,


physicians, nurses and clerks. The purpose is to measure
and monitor the business performance against the goal
model. Fig. 8 describes a performance report generated
from the dashboard which shows the measures of the
waiting time metrics and number of patients with respect to
time. The results of the performance report are monitored
with target values of the metrics.
The "Average Wait Time per Patient" chart in the
performance report, as in fig. 8, shows that the waiting
times have been reduced within one year. The percentage of
the improvement ranges between 30% and 50%. The
average time for Wait Time for Triage on November is
125.3 hours, while the target value defined in the goal
model is 60.0 hours. To achieve the business goal, several
procedures and recommendations have been ordered:
1. Resource Allocation has the highest impact on
monitoring the performance results by assigning the
available resources to multiple tasks. As an
example, when more registered nurses are assigned
for triage, the scheduled appointment time of triage
process assigned by the nurse contact is reduced
and this directly improves the Wait Time for
Triage.
2. Conducting trainings and improving skills increase
efficiency of the employee in performing the
business processes and reduce the number of
patients in the waiting queue.
3. Using advance technologies such as technologies
for tracking employees and patients will have a
great impact on reducing the waiting times.
4. Increasing the parallel execution of processes in the
business workflow, such as Nurse Contact and
Pending Result.
VII. FRAMEWORK EVALUATION
In this section, we compare our proposed framework
with respect to the common architecture of the BPM
traditional approach used in the TOH. The comparison is
based on three criteria described in table 2. In terms of
performance management, the business goals of the project
were defined in the traditional approach, however, the
requirement documents do not provide any clinical metrics
or the key performance indicators (KPIs) to measure the
achievement of the business goals. Also the deliverables of
the project do not specify any kind of reporting or
dashboard to show the status of the project. In our proposed
approach, we used the goal model to describe the business
goals, define the metrics to measure the outcome of the
business processes with respect to defined business goals,
and generate the performance report to evaluate the
compliance of the business goals.
In terms of the behavior specification, the traditional
approach uses the natural language to describe the
requirement documents which will cause confusion in

developing the business process scenarios. While in our


proposed framework, we improved the clarity of the
behavior specification by using the usecase map language
to model the business process scenarios.
In terms of tool support, the traditional support uses
only IBM BPM tool to model the business process of the
Lung Cancer Intake project. While in our proposed
framework, we used a complete set of modeling and
developing tools. The tools are: jUCMNav to describe the
requirement model, IBM BPM to build the business process
model and BI tool to generate the performance report.
TABLE II. COMPARISON BETWEEN TRADITIONAL APPROACH AND THE
PROPOSED FRAMEWORK

Performance
management
Behavior specification
Tool support

Traditional
Approach
Missing

Proposed
Framework
Model defined

Natural Language
Partial

Model Defined
Complete

VIII. CONCLUSION AND FUTURE WORK


The paper proposes a Requirement Modeling
Framework for developing online business processes that
bridges the gap between a performance metrics of the goal
model and the operational data model of the business
processes. The goal model provides performance metrics
that will measure the performance of online business
processes as they are being developed to ensure that the
development of online business processes quality is
improving. In general, traditional approaches relegate the
evaluation of business goals to the last stages of business
process development. In many situations the development
process proceeds without a real measuring of business goals
where metrics are computed and extracted from historical
data. The framework also uses scenario models to describe
the behavior of the business process rather than relying on
natural language specifications. As future work, we are
planning to use the model-driven methodology to allow the
mapping between the user requirement domain and the
business process domain. We demonstrate the proposed
frame work using a Lung Cancer Intake case study and we
intend to apply it on other health case studies.
ACKNOWLEDGMENTS
This work is supported by MITACS in collaboration
with IBM, the University of Ottawa and The Ottawa
Hospital (TOH).
REFERENCES
[1]

M. Alhaj and D. C. Petriu, "Approach for generating


performance models from UML models of SOA systems," in
CASCON '10 Proceedings of the 2010 Conference of the
Center for Advanced Studies on Collaborative Research,
Riverton, NJ, 2010.

[2]

[3]

[4]

M. Alhaj, "Automatic Generation of Performance Models for


SOA Systems," in Proceedings of the 16th international
workshop on Component-oriented programming, New York,
2011.
D. Amyot, "Introduction to the user requirements notation:
learning by example," Computer Networks: The
International Journal of Computer and Telecommunications
Networking - ITU-T system design languages (SDL), vol. 42,
no. 3, pp. 285 - 301, 2003.
A. Baarah, "An Application Framework for Monitoring Care
Processes,"
21
05
2014.
[Online].
Available:
http://www.ruor.uottawa.ca/handle/10393/30329. [Accessed
07 08 2015].

[5]

W. Branimir, Z. Ma and L. Frank, "Towards Measuring Key


Performance Indicators of Semantic Business Processes," in
11th International Conference on Business Information
Systems, Innsbruck, 2008.

[6]

J. L. de la Vara, J. Snchez and O. Pastor, "On the Use of


Goal Models and Business Process Models for Elicitation of
System Requirements," in 14th International Conference,
BPMDS 2013, 18th International Conference, Valencia,
2013.

[7]

C. Emig, J. Weisser and S. Abeck, "Development of SOABased Software Systems - an Evolutionary Programming
Approach," in Advanced International Conference on
Telecommunications and International Conference on
Internet and Web Applications and Services, Karlsruhe,
2006.

[8]

E. Gattnar, E. Okan and D. Vesselin, A Novel Generic


Clinical Reference Process Model for Event-Based Process
Times Measurement, vol. 97, Springer Link, 2011, pp. 65-76.

[9]

IBM, "IBM Business Process Manager," [Online]. Available:


http://www-03.ibm.com/software/products/en/businessprocess-manager-family/. [Accessed 01 08 2015]. 7

[10] Z. Jinyan, L. Xudong, N. Hongchao, H. Zhengxing and v. d.


A. M. P. W., "Radiology information system: a workflowbased approach," International Journal of Computer Assisted
Radiology and Surgery, vol. 4, no. 5, pp. 509-516, 2009.
[11] R. J. Lilford, C. A. Brown and J. Nicholl, "Use of process
measures to monitor the quality of clinical practice," British
Medical Journal, vol. 335, p. 648650, 2007.
[12] J. Mainz, "Defining and classifying clinical indicators for
quality improvement," International Journal for Quality in
Health Care, vol. 15, no. 6, pp. 523-530, 2003.
[13] OASIS Standard, Web Services Business Process Execution
Language Version 2.0, 2007.
[14] Object Management Group, Business Process Model and
Notation (BPMN) Version 2.0, 2011.
[15] L. Peyton, A. Baarah and M. Mouttham, "Architecture of an
Event Processing Application for Monitoring Cardiac Patient
Wait Times," International Journal of Information
Technology and Web Engineering, vol. 7, no. 1, pp. 1-16,
January 2012.
[16] F. Schrooyen, I. A. C. Baert, S. Truijen, L. Pieters, T. Denis
and K. Williame, "Real Time Location System over WiFi in

a Healthcare Environment," Journal on Information


Technology in Healthcare, vol. 4, no. 6, pp. 401-416, 2006.
[17] K. Shahzad and Z. Jelena, "A GoalOriented Approach for
Business Process Improvement Using Process Warehouse
Data," in Second IFIP WG 8.1 Working Conference,
Stockholm, 2009.
[18] A. Tegegne and L. Peyton, "Application framework support
for process-oriented software development," International
Journal of Electrical Business, vol. 10, no. 3, pp. 232 - 253,
2013.
[19] W3C, "SOAP Version 1.2," [Online]. Available:
http://www.w3.org/TR/soap/. [Accessed 13 08 2015].
[20] Q. Zhu, H. Nie, X. Lu and H. Duan, "Radiology workflowbased monitoring dashboard in a heterogeneous
environment," in rd International Conference on Biomedical
Engineering and Informatics, Yantai , 2010.

You might also like