Analytics Driven Application Development for Healthcare
Organizations
Omar Badreddin, Aladdin Baarah, Austin Chamney, Craig Kuziemsky and Liam Peyton
University of Ottawa, 800 King Edward st, Ottawa, Ontario, Canada
Keywords Clinical Information System, Interoperability, Application Framework, Healthcare Performance
Management.
Abstract: In response to governmental and regulatory mandates, Healthcare organizations are increasingly interested
in assessing the efficiency of their care processes and services. Traditional information systems for
healthcare have focused on capturing administrative details related to services and resource usage on a
departmental or healthcare provider basis. The resulting interoperability challenges make it difficult for
analytics and performance management reporting to provide a detailed view of care processes. This paper
presents a methodology and an analytics application framework that focuses on performance and efficiency.
Starting from performance goals, the application framework development is driven by the identified key
performance indicators. This methodology addresses interoperability challenges by defining the minimal
dataset required for measuring outcomes of a care process. It enables an information system design that
focuses on analytics and minimizes maintenance and integration issues. The application framework is
developed in the context of a multi-year case study of a clinical information system for palliative care.
1 INTRODUCTION
Performance management is gaining increasing
attention in healthcare. An aging population is
putting more pressure on healthcare organizations
that are already operating at full or near full
capacity. Healthcare organizations need to better
measure how care processes are achieving quality of
care goals and objectives in order to allocate
resources to processes that contribute most to their
stated objectives.
A further challenge is that many current
healthcare services are financially unsustainable. As
diagnostics and treatment options (i.e. personalized
medicine) extend people's life expectancy it puts
further pressure on resource allocation. Moreover,
governments want evidence-based healthcare
delivery and demand health organizations measure
operational efficiency. Hospitals struggle to balance
the operational necessities while pursuing regulatory
and governmental incentives that reward efficiency.
In an ideal situation, existing healthcare records
could be reused to generate performance reports to
justify financial expenditures. However, existing
healthcare records are collected with one main
objective, to support operations by providing records
for patients and care providers. This results in health
care records that are segmented with each setting
responsible for its own patients. Sharing and
integration of segmented data is expensive and
technically challenging due to different providers
and different resources from different organizations,
each with their own information systems. Further,
health records are subject to strict confidentiality
measures making data integration difficult. This is
particularly true when the care process involves.
Second, health records are often entered into
information systems from paper or voice-dictated
notes hours, days, or even weeks after the service
has been provided. This results in records that are
not available in real-time, and may reflect inaccurate
time stamps. Much of healthcare data is still paper
based which further adds to the integration
challenges. While many healthcare organizations
rely on data warehouses that use batch processes to
integrate data from various data sources to support
reporting requirements, it still often takes weeks for
data to be migrated from operational databases in
batch processes that populate the data warehouse for
consolidated reporting (Bates, 2010).
Because healthcare information systems are
mainly focused on capturing administrative details
135
Badreddin O., Baarah A., Chamney A., Kuziemsky C. and Peyton L..
Analytics Driven Application Development for Healthcare Organizations.
DOI: 10.5220/0004705001350142
In Proceedings of the International Conference on Health Informatics (HEALTHINF-2014), pages 135-142
ISBN: 978-989-758-010-9
Copyright
c
2014 SCITEPRESS (Science and Technology Publications, Lda.)
related to services and resource usage on a
departmental or healthcare provider basis, it results
in interoperability challenges that make it difficult
for analytics and performance management reporting
to provide a holistic view of care processes.
Our work with hospitals over the years to remedy
this always focused on refactoring or extending
existing systems to support the new performance
management requirements. This approach, while
feasible, faces key obstacles. First, this approach
does not deal with data integration. The
development team must integrate disparate data
sources and address privacy. Second, the cost of
refactoring existing healthcare systems is very high,
at times beyond the reach of smaller healthcare
institutions.
This paper presents a methodology and an
analytics application framework to provide
integrated information systems support for managing
care processes in terms of their outcomes. The
methodology identifies goals and key performance
indicators (KPIs) to measure these goals, and then
maps the KPIs to care processes. Forms are
developed to provide values for the identified KPIs.
This analytics application framework addresses
interoperability challenges by defining a minimal
dataset for reporting outcomes for a care process. It
supports system design that focuses on analytics and
minimizes integration issues. The framework was
developed in the context of a multi-year case study
of a clinical information system for palliative care.
This paper is organized as follows. We provide
the necessary background in the next section. In
section three, we give an overview of the
methodology. A case study is presented in section
four. We present the application model in section
five. Section six presents the analytics application
framework. We then present an evaluation of the
analytics driven application development approach.
A discussion of related work and conclusion
follows.
2 BACKGROUND
Performance management is concerned with
collecting data to quantify and measure outcomes
obtained by organizational processes in order to
determine how well they achieve organizational
goals and objectives (Pourshahid et al., 2009). A
significant challenge in implementing information
systems support for performance management of care
processes is to understand the relationship between
care processes and measured outcomes (Sandra et al.,
2011).
Electronic Health Records (EHR) have been
advocated as a tool to facilitate patient management,
provide performance measurement, and improve
quality of care. However, results have been mixed
(Bates, 2010), because of significant interoperability
challenges that arise in healthcare delivery (Kaplan
and Harris-Salamone, 2009), including technical,
process and organizational issues (Ash et al., 2004).
Research has also shown that EHR often improved
administrative requirements, with little improvements
to reporting and performance (Greenhalgh et al.,
2009).
In previous work (Mouttham et al., 2012), we
proposed a methodology for addressing
interoperability issues (Kuziemsky et al., 2008) for
managing community care of palliative patients in
terms of outcomes (Ferris et al., 2002). Phase one
(Peyton et al., 2012) made progess in addressing
interoperability but adoption was impeded by
complex data collection forms that. were not
practical for care providers. In phase two of the case
study, we used an application model for care process
monitoring introduced in (Baarah and Peyton, 2012)
to integrate it with a form-based application
framework that collects a minimal dataset into an
OLAP database (Inmon, 2005) for reporting
outcomes. The result is an application framework
that is agnostic about operational necessities, and is
focused on developing sufficient analytics to provide
performance management.
3 DEVELOPMENT
METHODOLOGY
Traditionally, record keeping requirements for
resource management and other operational
activities drive application form development in
healthcare organizations. This results in medical
forms that are extensive; forms that focus mainly on
operations, with little to no regard to performance
management requirements. When the time comes for
performance reporting, healthcare organizations
must aggregate data from multiple sources, some of
which may reside outside their healthcare
organization and are subject to privacy policies. This
process takes days and weeks before such
performance reports can be made available (Bates,
2010). For example, to report the number of days
patients wait for a procedure, the organization will
need information about the original referral, which
in many cases occurred outside the boundaries of the
concerned healthcare organization.
HEALTHINF2014-InternationalConferenceonHealthInformatics
136
Our development methodology is driven by
performance management requirements. Rather than
focus on solving operational requirements, we drive
our form development activities by analyzing the
objectives of the health care institution for a
particular care process, and analyze how such goals
are to be measured. The overview of the
methodology is illustrated in Figure 1.
Figure 1: Overview of the methodology.
3.1 Goal Hierarchy
Government and regulatory mandates are a source of
performance management requirements. These
requirements overlap and are frequently in conflict
of each other. Increasing the patient intake will
inevitably affect patient wait time negatively. These
requirements are modeled and conflicting objectives
are explicitly defined in goal models.
The first step in the methodology is to construct
goal models (Pourshahid et al., 2009); (Kuziemsky
et al., 2010); (Barone et al., 2011) that represent the
structure of objectives that the healthcare
organization tries to achieve. Examples of such
goals include reduce cost, reduce wait time of
patients, reduce patient readmission, maximize
resources utilization, etc.
Conflicting objectives are not a concern for our
methodology. This is because our application will
support measuring performance of the care process
against all objectives. The healthcare organization
can then review the relevant performance reports to
determine what actions, if any, they want to take to
resolve any conflicts between goals.
3.2 Identifying Key Performance
Indicators
The second step in the methodology is to identify
how each goal is measured. For example,
maximizing resources utilization can be measured
by counting the number of nights a bed or a room is
empty, or by counting the number of patients a
physician has seen over a specified period of time.
In the first case, the target might be to achieve zero
nights in which a room is empty, and in the second
case, the target might be an average of seven
patients per working day per physician.
Some regulatory requirements mandate how such
performance requirements to be reported upon. For
example, a regulatory requirement may mandate that
a patient who suffers from symptoms of a heart
attack must be seen within 60 minutes, or the
average wait time for patients at Emergency
department must not exceed 24 hours. In such cases,
the care institution has little freedom in deciding
which KPIs to collect. In other cases, which is not
uncommon, care institution can chose how to
measure and report on some performance
requirements.
KPIs can be course grained or fine grained. The
number of patients the healthcare organization
treated in a single day is an example of a coarse
grained KPI. The number of minutes a nurse was
idle is a fine grained measure. Clearly, find grained
KPIs may require additional records collection
which will typically result in complex and possibly
time consuming forms.
In this step, we work with the hospital teams to
decide on the minimal set of required KPIs and use
these KPIs to drive the application development.
The minimal data set is iteratively refined in close
collaboration with domain experts.
3.3 Mapping KPIs to Care Processes
Once the KPIs have been identified, we need to
determine what states of the care process they
correspond to and what data needs to be collected to
compute them. In this step, we perform mappings
(usually one to one mappings) between the KPIs, the
Database system, and the care process involved.
These mappings are relatively simple. Each KPI
corresponds to one database field. These simple
mappings ensure that the developed application is
agile. This is particularly important since reporting
and performance requirements are subject to change.
3.4 Application Development
At this step, forms are designed and integrated into
the flow of the care process. The form and a list of
look up values for each field in the form need to be
accessible by the care practitioner filling in the form.
The lookup tables for the form are defined by
considering both the needs of clinicians to document
what the process they are doing and the design of a
Goals
Hierarchies
Performance
re
q
uirements
KPIs
care
Processes
Application
Development
1
DB
2
4
3
Pilot
AnalyticsDrivenApplicationDevelopmentforHealthcareOrganizations
137
OLAP data model which will store the data and
support reporting of the measures. We effectively
determine which form, and which role will be
responsible for providing values for these KPIs.
Each form field corresponds to one or more KPIs
that have been identified in the previous steps. The
result is an application that has forms which fields
are directly linked to a data base model optimized
for reporting. In fact, during the review sessions,
form fields that do not contribute to performance
reports are removed from the application.
As with typical software development projects,
change requests are constant. This methodology
enhances change management in two ways. First,
tnstitution objectives and goals are less susceptible
to change as compared to operations and activities.
Second, change in how organizational goals are
measured and assessed are easier to handle. This is
because our application development maintains tight
integration with the identified KPIs.
The developed application is piloted for a period
of about 6 months, during which, functional and
usability concerns are identified. The piloting makes
available some realistic operational data, against
which sample performance reports can be generated.
Once the pilot project is completed, the application is
put on production servers, and ownership is
transferred to the hosting institution.
Before we introduce the application model in
section five, we present the case study next. The case
study illustrates the proposed methodology using
concrete goals, KPIs, and forms. This aids in the
presentation of the application model.
4 CASE STUDY
We have applied this methodology in the
development of a form-based analytics application
for a palliative care organization in Ontario. The
Palliative Information System (PAL-IS) is intended
to support a palliative care program that provides
consultations by an expert team of specialists for a
registry of palliative care patients. The system was
developed in two phases.
In phase 1, a web application was developed,
accessible by laptops over the Internet to capture
consultation data. The application was found to be
impractical to use in the field because of the huge
data entry burden. On average, 50 fields were
required per form. Many of them were complex and
most involved duplicate data entry into other
systems. A data entry clerk was hired to fill in forms
based on transcripts of dictated notes. Nonetheless,
the application was considered a success because it
provided reports that measured quality of care to
justify program funding and meet accreditation and
regulatory requirements.
The outcome of phase 1 motivated us to rethink
our development methodology. We observed that
healthcare favored solutions that brought little to no
change to their day to day activities. Later in the
development lifecycle, adoption was increased and
training needs were minimized, partly because care
providers did not need to adapt their activities. We
were also motivated by the fact that, despite the
forms being overly complex, healthcare organization
staff was determined to adopt the system. Their
motivation stemmed from their desire to see the
performance reports that the system generated
periodically and on demand.
In phase 2, PAL-IS was reinvented as a form-
based analytics application that focuses on
maximizing the value of the performance
management provided while minimizing the data
entry burden. This was particularly attractive for
those physicians who have started using smartphones
or tablets. The first step in designing the application
was to document and analyze the goals of the
program and define how outcomes would be
measured. Domain experts from the healthcare
organization were the main source for soliciting and
specifying the goal model. We have used their
existing documentation and review sessions to
validate our models. The final goal model was
verified with healthcare organization staff and with
the palliative care program managers.
Listing 1
illustrates a sample goal model for wait times.
Goal: Wait Time
Description: “This goal ensures that the average wait times
from referral to schedule an appointment and average time to
respond to alerts triggered by the palliative patients are
minimized”
Metrics: Average Wait_Triage Time, Average
Wait_FollowUp Time
Listing 1: Sample Goal model.
The listing shows a goal for Wait Times. The
goal ensures that the palliative care program is
responsive in a timely manner to referrals and alerts.
The second step is to identify the KPIs to
measure each goal. The main source of the KPIs was
reporting requirements and accreditation
specifications of the palliative care program. The
program director and team managers contributed to
the identification of the KPIs. The two KPIs for the
goal from listing 1 is presented in Listing 2.
Consider for example the metric
HEALTHINF2014-InternationalConferenceonHealthInformatics
138
Average_Wait_Time, which is the amount of time
the patient was waiting for Triage. This is calculated
to be the time from referral to an appointment (see
Figure 3). The target for this measure is a value less
than 7 days. The KPIs also specifies which alerts to
fire when the target is not achieved.
Metric: Average Wait_Triage Time
Description: “This metric measure the average
time the palliative patients wait once
they are referred to the palliative care
program until a scheduled
appointment is booked”
Computation: AVERAGE STATE:
WAIT_TRIAGE. duration Over
Period of Time
State: WAIT_TRIAGE
Events: Referral
Target: <7 days
Alert: WAIT_TRIAGE_WARNING,
WAIT_TRIAGE_UNACCEPTABLE
Metric: Average Wait_FollowUp Time
Description: “This metric measure the average
time the palliative patients wait when
abnormal condition occurred until a
consult occurs”
Computation: AVERAGE STATE:
WAIT_FOLLOWUP. duration
Over Period of Time
State: WAIT_FOLLOWUP
Events:
Status:
Target: <=4hours
Alert: WAIT_FOLLOWUP_WARNING,
WAIT_FOLLOWUP_UNACCEPTABLE
Listing 2: Sample KPIs.
Next, we identify at which step of the care
process these measures are to be collected. We refer
to the application model of the process to indicate
where in the process to collect measures for these
KPIs. The model is explained in detail, in the next
section. In this step, we effectively identify the
minimal dataset to be collected to provide operational
measures for the identified KPIs.
The final step is to implement a forms-based
application for care process analytics that links a
simple user interface for forms with a data base
model optimized for reporting outcomes. The
palliative team has collaborated closely with us to
design the forms and perform user testing of the
system.
The forms were designed so that they can be
completed on a mobile device, or a laptop computer.
In fact, one of the guidelines we followed was to
make sure that all fields to be viewable on a single
screen. This is to minimize the need for forward and
backward navigation. We achieved this by using
multiple drop-down menus whose values are
dependent on other fields in the form. For example, if
the patient under examination is at home, the rest of
the form fields eliminate questions or fields that are
related to patients that are in the healthcare
organization.
Each report had links to where the data is
originating from. One or more form fields contribute
to each data point in the report. Form fields that had
no report contribution were removed.
5 APPLICATION MODEL
The application model defines goals in terms of the
metrics which are reported to measure outcomes.
Those metrics are mapped to a simple state transition
diagram which identifies the key patient states and
events in the care process for which the data that
must be collected. Forms are defined for each event
to collect this required data.
Figure 2 maps goals to metrics to forms. For each
metric, the form(s) that collect data for the metric is
shown in parentheses (e.g. “Referral” is the form
used to count “# of Patients Cancer”).
The first set of goals (“Care”) is related to
understanding the quality and coverage of care
provided. To ensure coverage of the patient
population (“Demographics”), a “Referral” form
captures the data for “# of Patients Cancer” and “Non
Cancer” (with drill down into diagnosis, gender, and
age). To ensure “Wait Time” is minimized, the
“Average Wait_Triage” time (from “Referral” to
“Appointment”) is measured as well as “Average
Wait_Followup Time” taken to respond to alerts
(from “Alert” to “Consult”). Finally, “Outcomes” are
measured to ensure “# of Alerts” is minimized
(patients should be stabilized) and to track the
number of unnecessary interventions during a
patient’s last days (“Decease” form).
The second set of goals is used to measure how
effective the program is in promoting palliative care
to facilities and physicians so the number of referrals
by physician and facility is captured. As well, the “#
of Consults With Resident Present” is tracked
(“Consult” form).
Figure 3 illustrates the state transition diagram
that identifies the key patient states for the palliative
care process and identifies when forms are used to
collect data. The process begins with a “Referral”
form from a physician or facility. Then, an
“Appointment” form schedules a consult. If the
patient’s condition is stable, then repeated a
“Consult” form is followed by an “Appointment”
form for the next regularly scheduled consult until
AnalyticsDrivenApplicationDevelopmentforHealthcareOrganizations
139
Figure 2: Performance management of palliative care goals based on outcomes.
Figure 3: Palliative care process state.
there is either a “Decease” form or a “Discharge”
form (if no longer considered terminally ill). But if
something goes wrong, an “Alert” form captures the
issue and the patient waits for a follow up
consultation (recorded by a “Consult” form). After
the follow up, the patient returns to whatever state
they were in when the alert occurred
(Wait_Scheduled or Unscheduled).
6 EVALUATION
Table 1
below summarizes the advantages of an
information system design based on our analytics
driven application development over the customized
web application based on a complete Electronic
Health Record (EHR) that was created in Phase 1.
First, the methodology used has greatly reduced the
complexity of PAL-IS. In Phase 1, any change to the
system required deep knowledge of the entire
application logic and the particular way forms and
data were combined. Now, an HTML designer can
optimize the look of a form for usability based on
user feedback and then make a simple call to one of
the API calls to link it to lookup tables and queries
defined in the database. The core middleware logic is
application independent and off the shelf. The
application is available on any device and shows only
the reports or forms specific to the user.
Finally, the application model enabled us to
identify the minimal data set needed to measure
performance. This greatly reduced the number of
fields and thus reduced the data entry effort. It also
ensured that goals were directly linked to reports and
data collection forms. Building the application model
also brought us in contact with all stakeholders of the
organization ensuring full information support for all
roles, not just the front line care providers that were
addressed in Phase 1.
7 RELATED WORK
The use of goal models to support Health Care
HEALTHINF2014-InternationalConferenceonHealthInformatics
140
Table 1: Evaluation of phase 2 analytics application framework.
Criteria Phase 1 (Complete EHR) Phase 2 (Analytics Application)
System Maintenance
Effort
Forms, data mixed. Customized system.
Significant custom support
Separate but linked forms & data. Off the shelf system.
Low maintenance support.
Data Entry Effort
~ 50 fields per form. Many complex fields. ~ 10 simple fields per form.
Ease of deployment
Desktop or laptop. Any device (phone, tablet, laptop, PC…).
Usability
One complex interface for all users.
Reporting disconnected from forms.
Individualized interfaces shows only relevant forms and
reports (Linked).
Organizational Goals
Information system disconnected from goals. Application model links goals to reports to forms.
Organizational Roles
Focused on front line care providers. All roles by forms / reports linked to goals.
analytics has been investigated in a number of
studies (Ferrand, 2010); (Ghanavati et al., 2010);
(Barone et al., 2010); (Barone et al., 2011). These
approaches typically utilize a goal modeling
notations, such as GRL and i*, and reports
compliance and performance against those models.
Kuziemsky et al., (2010) proposes a five step
methodology to help identify the impact of health
care informatics on the organization goals, such as
quality of care. Ferrad (2010) applied an analytics
framework to reduce the number of adverse events
in healthcare. Their approach quantifies the source
of adverse events using goal models and metrics.
Goal models are also used to assess the effectiveness
of business strategies while ensuring that medical
regulations and guidelines are respected (Ghanavati
et al., 2010).
The gap between operational details and high
level organizational objectives have been identified
and discussed in a number of industries (Barone et
al., 2011) as well as in healthcare (Behnam and
Badreddin, 2013). A number of approaches have
been suggested to bridge this gap, including the use
of Business Intelligence Models (Barone et al.,
2010) to represent the business view, and
Conceptual Integration Model to represent the data
collection and reporting view.
8 DISCUSSION
Performance management and compliance are
increasingly playing a significant role in many
industries. In our previous work, we have developed
a methodology that enables organization translate
their regulatory documents into performance models
to support business analytics reports (Badreddin et
al., 2013). This work expanded earlier work by
looking at the issue that regulations are drafted with
little regard to how the compliance of regulations
will be measured. Medical forms are designed and
implemented without sufficient understanding of
analytics and compliance requirements. This can be
attributed to the fact that software development is by
and large driven by functional requirements for
operational necessities.
The key contribution of this paper is a new
paradigm for application development for healthcare
institutions. This paradigm is based on performance
driven application development where each field in
the medical form is driven by a performance
management requirement, rather than operational
requirements. This results in significantly simpler
forms that can be completed on smartphones or
tablets as part of the care giving activity. It reduces
the need for integrating disparate data sources for
performance management, and is significantly more
agile in the face of change. More importantly, this
approach ensures that the required data for analytics
reports are readily available and accessible.
Our experiences indicate that operations staff is a
key source in requirement specifications, but it is the
management team that is more concerned with
performance management. That results in patient
records that do not support business analytics. Our
work also showed that focusing primarily on the
analytics and compliance requirements can result in
simple systems that are easy to use, and satisfy
enough functional requirements to ensure adoption.
While the trend in software engineering is
towards big data; symbolized in massive data
collection, storage, and analysis, this approach can
result in excessive overhead and costs. involved.
Healthcare is a domain where small data can at least
as successful. Less data means fewer patients'
privacy concerns. In this paper, we have
demonstrated that small data should also be
considered when applicable.
AnalyticsDrivenApplicationDevelopmentforHealthcareOrganizations
141
9 CONCLUSIONS
We have presented a novel methodology and
application model. In this approach, the development
of applications are driven by performance reporting
requirements. The approach starts by identifying the
healthcare organization goals and the key
performance indicators to measure those goals. Fields
in the application forms are directly related to these
KPIs. This results in forms that satisfy the analytics
requirements, while keeping the form as simple as
possible. Out work has resulted in two major
contributions for the palliative care team. First, it
provides information system support that delivers
clear insight for all roles in the organization through
reports on palliative care process delivery. Second, it
has reduced the data entry burden to the point where
care providers can use their phones for dictation and
then tap on a few fields to provide essential data for
performance management.
ACKNOWLEDGEMENTS
We thank the Palliative Care Consultants team at
Élisabeth Bruyère for their participation,
collaboration and financial support. This research
was also financially supported by a MITACS
internship and an NSERC discovery grant.
REFERENCES
Mouttham, A., Kuziemsky, C. D. Langayan, L. Peyton,
and J. Pereira, Interoperable Support for Collaborative,
Mobile, and Accessible Health Care, Information
Systems Frontiers, 14 (1), 73-85, 2012.
Bates DW. Getting in Step: Electronic Health Records and
their Role in Care Coordination, J Gen Intern Med
25(3):174–6, 2010.
Kaplan, B. and Harris-Salamone, K. D, “Health IT success
and failure”. Journal of the American Medical
Informatics Association, 2009, 16(3), 291-299
Ash, J.S, Berg, M and Coiera, E “Some Unintended
Consequences of Information Technology in Health
Care: The Nature of Patient Care Information System-
related Error” J Am Med Inform Assoc, 11, 2004, 104–
112
Ferris, H. Balfour, K. , Bowen, J. Farley, M. Hardwick, ,
C. Lamontagne, M. Lundy, A., Syme and P. West,” A
model to guide hospice palliative care: Based on
national principles and norms of practice”, Canadian
Hospice Palliative Care Association Ottawa, 2002
Kuziemsky, J. H., Weber-Jahnke, F., Lau, and G. M.
Downing. “An interdisciplinary computer based
information tool for palliative severe pain
management. Journal of the American Medical
Informatics Association”, 2008, 15(3), 374–382.
Inmon, W. H., Building the data warehouse. 4
th
edition,.
Indianapolis: Wiley Publishers, 2005.
Baarah, A. and Peyton, L., ” Engineering a State
Monitoring Service for Real-Time Patient Flow
Management”, Middleware 2012, Montreal, Canada,
December, 2012.
Peyton, L., Kuziemsky, C. and Langayan, D. “A Case
Study in Interoperable Support for Collaborative
Community Healthcare”, Software Engineering in
Healthcare 2012, Zurich, Switzerland, June, 2012
Sandra G. Leggat, Timothy Bartram, Pauline Stanton,
"High performance work systems: the gap between
policy and practice in health care reform", Journal of
Health Organization and Management, Vol. 25 Iss: 3,
pp.281 – 297, 2011
Pourshahid, D. Amyot, L. Peyton, S. Ghanavati, P. Chen,
M. Weiss, A. J. Forster, “Business Process
Management with the User Requirements Notation”,
Electronic Commerce Research, Springer, Vol. 9 No.
4, pp 269-316, 2009.
Kuziemsky, C., Xia Liu, and Peyton, L. "Leveraging Goal
Models and Performance Indicators to Assess Health
Care Information Systems." Quality of Information
and Communications Technology (QUATIC), 2010
Seventh International Conference on the. IEEE, 2010.
Badreddin, O., Mussbacher, G., Amyot, D., Behnam, S.,
Rashidi-Tabrizi, R., Braun, E., Alhaj, M. and
Richards, G.: “Regulation-Based Dimensional
Modeling for Regulatory Intelligence”. RELAW 2013,
Sixth International Workshop on Requirements
Engineering and Law.
Behnam, S. and Badreddin, O. "Toward a Care Process
Metamodel”. Proceedings of 5th International
Workshop on Software Engineering in Health Care
(SEHC 2013).
Ferrand, D. "Towards A Business Intelligence Framework
For Healthcare Safety." Journal of Internet Banking
and Commerce 15.3 (2010).
Ghanavati, S. et al. "Integrating business strategies with
requirement models of legal compliance."
International Journal of Electronic Business 8.3
(2010): 260-280.
Barone, D., Mylopoulos, J., Jiang, L., Amyot, D.:
Business Intelligence Model, version 1.0. Technical
Report CSRG-607 (ftp://ftp.cs.toronto.edu/csri-
technicalreports/INDEX.html), University of Toronto
(March 2010).
Barone, Daniele et al. "Towards model-based support for
managing organizational transformation." E-
Technologies: Transformation in a Connected World.
Springer Berlin Heidelberg, 2011. 17-31.
Greenhalgh T, Potts H. W., Wong G.: Tensions and
paradoxes in electronic patient record research: a
systematic literature review using the meta-narrative
method. Milbank Q 2009; 87:729–788.
HEALTHINF2014-InternationalConferenceonHealthInformatics
142
