See discussions, stats, and author profiles for this publication at: https://www.researchgate.

net/publication/11007048

Towards elicitation of users requirements for hospital information system: from

a care process modelling technique to a web based collaborative tool

Article  in  Proceedings / AMIA ... Annual Symposium. AMIA Symposium · February 2002

Source: PubMed

CITATIONS READS

2 272

4 authors:

Pascal Staccini Michel Joubert

University of Nice Sophia Antipolis Aix-Marseille Université
167 PUBLICATIONS   2,282 CITATIONS    65 PUBLICATIONS   675 CITATIONS   

SEE PROFILE SEE PROFILE

Jean François Quaranta Marius Fieschi

University of Nice Sophia Antipolis Aix-Marseille Université
160 PUBLICATIONS   1,695 CITATIONS    271 PUBLICATIONS   1,696 CITATIONS   

SEE PROFILE SEE PROFILE

Some of the authors of this publication are also working on these related projects:

Mise en place de Dossier Patient Informatisé (DPI)au Burundi View project

TRANSFUSION REACTION View project

All content following this page was uploaded by Jean François Quaranta on 27 May 2015.

The user has requested enhancement of the downloaded file.

 Towards elicitation of user requirements for hospital information systems:
from a care-process modeling technique to a web-based collaborative tool
Pascal Staccinia,b,d, MD, MS, Michel Joubertc, PhD,
Jean-Fran ois Quarantad, MD, Marius FieschiC, PhD
bDepartement d'Information Medicale, CHU Nice, France
bSTIC, Faculte de Medecine, Universite Nice-Sophia Antipolis, Nice, France
CLERTIM, Faculte de Medecine, Universit6 de la M6diterran6e, Marseille, France
dCoordination des Vigilances Sanitaires et de la Gestion des Risques, CHU Nice, France
Growing attention is being given to the use ofprocess advocating care-process analysis as an effective
modeling methodology for user requirements elici- means of federating both objectives and rules of
tation. In the analysis phase of hospital information practice and management. The French accreditation
systems, the usefulness of care-process models has manual contains several references focussing on
been investigated to evaluate the conceptual evaluation of the performance of care processes. The
applicability and practical understandability by factors and the levels of quality and security of care,
clinical staff and members of users teams. as well as coordination of care activities and data
Nevertheless, there still remains a gap between users exchanges between the various parties involved are
and analysts in their mutual ability to share required to be traced, measured and analysed.
conceptual views and vocabulary, keeping the The second key point that could explain the growing
meaning of clinical context while providing elements interest in process analysis involves hospital
for analysis. One of the solutions for filling this gap information systems. From a technical point of view,
is to consider the process model itself in the role of a process-oriented information systems that implement
hub as a centralized means offacilitating communi-
cation between team members. Starting with a robust workflow technology are deemed to be valuable for
and descriptive technique for process modeling the clinical personnel since they actively support the
called IDEFO/SADT, we refined the basic data model processes in a hospital and reduce administrative
by extracting concepts from ISO 9000 process overheads: 1) by proposing tasks "just in time" when
analysis andfrom enterprise ontology. We defined a all the necessary information is available to perform
web-based architecture to serve as a collaborative them; 2) by respecting deadlines and other time
tool and implemented it using an object-oriented constraints6. For the analysis phase, process-based
database. The prospects ofsuch a tool are discussed modeling can provide a rational means of organizing
notably regarding to its ability to generate data information: 1) that is processed to perform care
dictionaries and to be used as a navigation tool activities; 2) that can be requested by a concerned
through the medium of hospital-wide documentation. party, conveyed to him/her according to the work
context, or simply be available7.
INTRODUCTION The third key point is related to the lack of
Process-oriented management is emerging as a more involvement of medical staff in the design and
and more relevant approach for managing healthcare implementation of information systems, because of
organizations as well as for guiding the analysis of the failure of information systems to achieve their
patient-centred information systems12,344. A number true potential8. The reasons for this are the difficulty
of key points help to account for this fact. or inability to define both system and user needs, and
First of all, changes in the economic background in the poor description of the organizational context in
terms of cost reductions, and the increase in social which system and users will operate. Although the
expectation as regards safety of care have induced elicitation of user requirements is considered to be a
hospital managers and clinical staff to define, very serious issue, it has rarely been dealt with
implement and evaluate new hospital management successfully. Capturing and formalizing end-user
programs. Currently, in France, all care requirements remains a complex task as clinical staff
establishments, private as well as public, are involved are not well-equiped to describe system needs as
in the mandatory procedure of accreditation well as their own. The importance of design being
conducted by the French agency for the evaluation driven by a detailed understanding of patient care
and accreditation of healthcare5. To assist processes has been highlighted, as opposed to
implementation of this nation-wide health-care addressing individual or unrelated tasks'0. Even
evaluation program, a strong body of opinion is though the patient care system provides better data

AMIA 2002 Annual Symposium Proceedings 732

entry and retrieval, it must fit actual patient care
processes and work situations. As the tendency of
clinical practice is to move to a shared care
environment, the knowledge of clinical systems
includes the characterization of all aspects of the
clinical processes, as well as the functions and
responsibilities of the people involved in its.
All those key points are strongly related with the
methodological foundations of continuous quality
improvement in healthcare, the evolution of the
ISO 9000 norms that promote enterprise process
analysis", and the use of business process
redesigning to help cross-functional enterprises view
and describe their major processes'2. Consequently,
clinical information systems must satisfy two kind of
clients. They have to provide end-users with full
event traceability, real-time data entry and retrieval
features, context-based decision supply and
measurement of the perfornance of activities. They
must also reassure patients that everything is being
done in compliance with practice and organizational
rules. These need to be well-known to the staff,
permanently available and should have been drafted
by multidisciplinary workgroups, and promulgated as
the legally-binding rules or the best rules for
providing care. Measures need to be taken by
national evaluation agencies to check that the
organization effectively does what it purports to5.
OBJECTIVES
When describing and refining their practice in order
to clarify and remedy dysfunctions, the clinicians
involved need methods and tools to help them create,
classify and publish their findings. These results must
provide everyone concerned with shared, relevant
and coherent views regarding the organization'3 that
they are (re)constructing using "building blocks" in
the form of processes, sub-processes and tasks.
Because clinicians are not analysts, they need
meaningful tools to assist them in describing their
practices. As analysts are far-removed from clinicians
and care processes, they need to extract models from
the detailed routine, in order to identify datasets,
formalize dataflows, define mandatory data and
understand the context of user needs. One solution is
to define a process model that can be easily
understood by a clinician and used to outline a
clinical process in terms of roles, activities,
documentation, objectives and indicators. This same
model must provide the analyst with technical views
in terms of data items, forms, and document sources.
The process model acts somewhat like a hub,
providing a centralized means to facilitate
communication between team members.
The purpose of this paper is to present and discuss
the methodology we followed in order to: 1) refine
733
the basic process model that we used previously to
guide elicitation of user requirements for the
trinsfusion process'617; 2) and design the process
analysis tool that implements this refined process
model and provides relevant views for both clinical
staff and analysts.
METHOD
Whatever their purpose, all models have one
characteristic: the mapping of elements in the system
modelled into the model. Generally, for process
modeling, a pragmatic and technique-oriented
definition is provided by Davenport who defines a
process as "a specific ordering of work activities
across time and place, with a beginning, an end, and
clearly identified inputs and outputs: a structure of
action"'4. Dealing with various contexts and various
levels of granularity, an atomic component of a
process has to be defined. This indivisible element is
intended to express the notion of any form of activity.
The basis of our process model is the functional
element of the SADT/IDEFO (Integrated DEfinition
for Function modeling) for activity modeling
technique" that we used in previous works'6.
IDEFO model activity is symbolized by the ICOM
box (I for inputs, C for controls, 0 for outputs and M
for mechanisms (figure 1), which are the four types
of activity interface). In order to further refine our
description of activity, we looked for a more accurate
grammar in the field of Enterprise Ontology'8. We
also extracted concepts from the ISO 9000:2000
specifications, in order to improve the semantics of
an activity. Dealing with the description of resources,
we integrated Dublin Core metadata project recom-
mendations'9. After this refinement step, we designed
the data model and the architecture of the process
analysis tool. We implemented it as a web-based
application running under Zope (Z Objects
Publishing Environment)20 in connection with the
PostgreSQL relational database.
RESULTS
Refinement of the process model
We kept the hierarchical architecture of the IDEFO
technique, that is the top-down division of a process
into sub-processes and tasks and the break-down of
sub-processes into elementary tasks or activities. We
considered that a process is composed of sub-
processes and elementary tasks, but that sub-
processes are composed only of tasks. Task is defined
as the smallest and indivisible functional element of a
process. Some specifications of the ISO 9000:2000
norm have been chosen to precise the description of
mechanisms and controls according to the "5M"
checklist: Men, Machines, Materials, Methods,
Medium (figure 1). For the category "Methods", we
refined its characterisation with: I) the type of
content (rule, manual, guideline, procedure,
instruction, record, planning); 2) the format of the
support (folder, form, sheet, file); 3) and the source of
content (legal, local, scientific society, agency). For
the category "Men", we adopted the semantics of
Enterprise Ontology to define functions, skills needed
and levels of responsibility. We introduced in the
IDEFO model activity the representation of strategy
in terms of demands, objectives, criteria, threshold.
The notion of measurement has also been delimited
(conformity, adverse event, delay). For each
objective, the factors, whether critical or successful
can be defined. Factors may have their own objective
and measurement. We also determined the type of
activity (choose, decide, sign, check, fill, report,
monitor, read, send, receive, acknowledge, transmit,
call, operate, examine). Items and sets (groups of
items) have been created to populate the interface of
a task. Table I shows the complete list of the terms
defined in our process model, and extracted from the
IDEFO activity modeling technique, ISO 9000:2000
norm and Enterprise Ontology.

K!) Task P input (I) ziV4 JnptOutput (0)|

t
t
(0)
~~~~~~~~~~~~~~Strategy
Objectives
~~~~~~~~~~~~-
factors
Men Machines * requirement
Resources * function * materials * criteria
Mechanisms (M) cpskill * equipment measurement
* capability * threshold
* responsibility
Figure 1: Refinement of the basic functional element of the IDEFO activity modeling technique (left side) with
specification of resources (men and machines) and specification of control (methods and medium) (right side)
Table 1: Grammar defined to describe type, content and hierarchy of the components of a process to be used for the
implementation of the web-based process analysis tool
Type of component Item, Set, Task, Role, Sub-process, Process
Identity of a component Title, Description, Creation date, Modification date, Author
Item Type [data element; document, file, criterion], Subtype [boolean, float, integer,
long, string, text, rule, manual, guideline, procedure, instruction, record, planning],
Default value, URL, Source [legal, local, society, agency]
Set Type [dataset, folder, form, indicator], Subtype [conformity, adverse event, delay]
Task Type [choose, decide, sign, check, fill, report, monitor, read, send, receive,
acknowledge, transmit, call, operate, examine], Input, Output, Role, Authority,
Task owner, Function, Capability, Skill, Resource, Resource allocation, Resource
substitute, Materials, Equipment, Methods, Conditions
Strategy Purpose, Hold purpose, Intended purpose, Strategic purpose, Requirement,
Objective, Help achieve, Criterion, Measure, Threshold, Influence factor, Critical
influence factor, Non-critical influence factor, Critical success factor, Risk

web-based interface, an object-oriented database, a

Design and implementation of the web-based tool
We implemented the data model and the grammar of
the process model in an open source programming
environment. Zope is a framework for building web
applications. It comes with a built-in web server, a
relational integration and a scripting language support
(Document Template Markup Language (DTML)).
The architecture of the application was designed to
separate elementary components of a process and
combinations of them into sets, tasks, sub-processes

734
 .
and processes (figure 2). This architecture contains
four parts: 1) a set of libraries that store all the
components that can be combined; 2) a relational
table (and the methods to query it) which stores the uiiad
Du----|
relationships, the hierarchy and the sequence order
between components; 3) a set of procedures that
process information according to user interaction; 4)
a single template document used to format, display
information and build user interface. A specific
object stores all the parameters to configure user
interface and the values to describe the type and the
content of components. All components are described
with a same set of attributes compliant with Dublin
Core metadata.
For each library, a pack of functions has been defined
in order to access each component, edit its properties,
delete it under user control, add or remove sub-
components, browse the entire library and list parents
of each component (figure 3). Predefined queries
have been written to generate: 1) the data dictionary
of one or many selected processes, listing all the data
elements and their origin as defined when describing L~~~ -am - I ...

the tasks; 2) the list of all the documents that have Figure 2: Architecture of the web-based tool from
been gathered to help all people involved to perform the location of objects in an object-oriented
their tasks, and that have been linked to one or more repository to the description of the relationships
task in the process. between components in a relational database

..

------------------------------------------
I_...J
.tee.s IJ. Ss J li .ss. T...... !*wess | e. eses

I
4
1
I
_~~~~~~~~~~~~~~~~~~~etasue codn oidcto isre n- douens ite isaniain
IS-rdeckle
lloyt pmdmU P ) tec nestbtskrlduc o d predct.s
USchop
2 - n (Ud p) us M d bod poducts
-3 -deddn bUtP) M-~~~~~~~~~~~~~~~~su
_ ta at tf X wdof which ft phyve wi dciX or not if X jwn pai hs toI
*4 choos lab tests Mr , _ _ l W~ ~ ~ ~ b trawud ceordh to ildcaftio nJs dW in Iq docunts. if there is mn imkdicto,I
3 - ofdering (SP) the physka vI choose ths type of products ftt fit to the patsnt, by appir the nAes of
4- Mr (SP) the next ta XedIhmoas blad prBducts'.I
Xs5 - mceipt (S) om
-pi (SP) ___ ...............

BNWrf
7- (S)ow
I

Padent Icirc. 30juin 190

Ipatiet
U Icic. 17 ma 1985
circ. 28 seCt 1107
Ikg 4 jaVisr 1993

I~~~~~~~~~~~~~~~~~~af .kA
_I _ 1 _l

Figure 3: Screen-shot of user interface with: 1) tabs-based navigation to browse the content of component libraries;
2) set of component functions; 3) view of component properties; 4) contextual view of the items linked to the
selected component and classified according to the type of link; 5) tree-view of the process and its components
ranked according to the sequence arranged by the user.

735
 DISCUSSION
There has been some debate regarding the usefulness
of process models in an analysis phase. In an analysis
phase, process models can help users to find their
way through the process. They can be used to
interview users, managers and other stakeholders.
The model is used to reveal the process, the roots of
its problems, and possible trouble-shooting methods.
In the design phase, the analyst's problem is to obtain
an overview of organizational features such as
process, control, dataflow, roles and goals7. Other
features such as skill requirements and organization
norms are more difficult to represent but are
essential. This approach could help hospital teams to
identify and build a classification of processes that is
useful in implementing process-oriented management
methods. The aim of our project was to create a web-
based collaborative tool, based on a given method of
process modeling that we had previously tested on
clinical staff'6"17. The tool is based on a robust
process model. One process (transfusion process) has
already been mapped. We plan to work on
transplantation and hip repair processes. Members of
process-based reengineering teams are now able to
standardize descriptions of care processes while
keeping organizational and clinical relevance. This
technique provides them with an overview of process,
sub-processes and tasks, and with a convenient
method for arranging components and assigning
roles. It empowers clinical staff to extract useful
documentation to be shared with the systems analyst
in the shape of a data dictionary with customized
views according to role of staff member concerned.
The different data dictionaries that can be generated
from this process database, can be of value when
dealing with data quality2". It can also provide a
starting point for the construction of a documentary
system based on all types of documents described
and related to specific tasks and roles.
References
1. Plsek PE. Systematic design of healthcare
processes. Qual Health Care 1997;6:40-8.
2. Amberg M, Graber S. Specifying hospital
information systems using process modeling, In:
Brender J, Christensen JP, Sherrer JR, McNair P
editors. Medical Informatics Europe '96.
Amsterdam: IOS Press; 1996. p. 1037-41.
3. Ehlers F, Ammenwerth E, Haux R, Pohl U, Resch
F. Analysis and modelling of the multi-
professional treatment process: preliminary
results. Medinfo 2001;10(Pt 1):324-8.
4. Vassilacopoulos G, Paraskevopoulou E. A
process model basis for evolving hospital infor-
mation systems. J Med Syst 1997;21:141-53.
736
View publication stats
5. Matillon Y. The process of accreditation is clearly
launched. Soins 2000;644:7-10.
6. Dadam P, Reichert M. Towards a new dimension
in clinical information processing. Stud Health
Technol Inform 2000;77:295-301.
7. Kueng P, Kawalek P. Goal-Based Business
Process Models: Creation and Evaluation,
Business Process Management Journal
1997;3: 17-38.
8. Colreavy P. Lack of Adequate Medical
Involvement in Patient Centred Information
Technology. Stud Health Technol Inform
2000;77:51-6.
9. Metzger JB, Teich JM. Designing Acceptable
Patient Care Information Systems. In: Patient
Care Information System - Successful Design
and Implementation, New-York: Springer-Verlag
1996. p. 84-132.
10. Sutcliffe A, Jarke M, Rolland C, Bubenko J,
Constantopoulos P. Defining Visions in Context:
Models, Processes and Tools for Requirements
Engineering. Information Systems Journal
1997;21 :515-547.
11. Sim P. ISO 9000:2000 revisions and their
implications. Med Device Technol 2000; 11:45-7.
12. Malhotra Y. Business Process Redesign: An
Overview. IEEE Engineering Management
Review 1998;26:27-3 1.
13. Herlea DE. User's Involvement in the
Requirements Engineering Process. Proceedings
of the Workshop on Internet-based groupware for
users involvement in product development; 1998,
Seattle USA. p. 25-30.
14. Davenport T. Process Innovation, Boston:
Harvard Business School Press; 1993.
15. Ross DT. Applications and Extensions of SADT.
Computer 1985;18:25-34.
16. Staccini P, Joubert M, Quaranta JF, Fieschi D,
Fieschi M. Integration of health care process
analysis in the design of a clinical information
system: applying to the blood transfusion process.
Proc AMIA Symp 2000;:824-8.
17. Staccini P, Joubert M, Quaranta JF, Aymard S,
Fieschi D, Fieschi M. Towards Health Care
Process Description Framework: an XML DTD
Design. Proc AMIA Symp 2001;:647-5 1.
18. Ushold M, King M, Moralee S, Zorgios Y. The
Enterprise Ontology. The Knowledge
Engineering Review 1998; 13:31-89.
19. Dublin Core qualifiers. http://dublincore.org/docu
ments/dcmes-qualifiers/ (last visited: 1/03/2002).
20. http://www.zope.org (last visited 1/03/2002).
21. Storey VC, Wang RY. Modeling Quality
requirements in Conceptual Database Design.
Proceedings of the Conference on Information
Quality; 1998; Cambridge MA. p. 64-87.