Content uploaded by Romaric Marcilly
Author content
All content in this area was uploaded by Romaric Marcilly on Apr 13, 2015
Content may be subject to copyright.
Medication Related Computerized
Decision Support System (CDSS): Make it
a Clinicians’ Partner!
Romaric MARCILLY a,1, Nicolas LEROY a, Michel LUYCKX b, c, Sylvia PELAYO a,
Costanza RICCIOLI d and Marie-Catherine BEUSCART-ZÉPHIR a
a
INSERM CIC-IT, Lille, CHU Lille; UDSL EA 2694; Univ Lille Nord de France;
F-59000 Lille, France
b Faculté des Sciences Pharmaceutiques et Biologiques, UDSL2, Univ Lille Nord de
France, F-59000 Lille, France
c Centre Hospitalier de Denain, France
d
Kite Solutions, SNC, Via Labiena 93, 21014 Laveno Mombello (Va), Italy
Abstract. Medication related Computerized Decision Support System (CDSS) are
known to have a positive impact on Adverse Drug Events (ADE) prevention but
they face acceptance problems due to over alerting and usability issues. We
present here a Human factors approach to the design of these Clinical Decision
Support (CDS) functions and to their integration into different Electronic Health
Record (EHR) / Computerized Physicians Order Entry (CPOE) systems, so that
the resulting CDSS corresponds to the users needs and fits clinical workflows and
cognitive processes. We used ethnographic observations completed with semi-
structured interviews to analyse existing work situations and work processes.
These were then described in detail using the SHEL (Software, Hardware,
Environment & Liveware) formalism, which enables a structured description of
the work system and provides an appropriate classification of human errors
potentially leading to ADEs. We then propose a Unified Modelling Language
(UML) model supporting the characterization by the CDSS of the drug monitoring
and clinical context of patients at risk of ADE. This model combines the status of
the lab test orders on the one hand with the validity and normality of the lab results
on the other hand. This makes the system able to catch the context of the
monitoring of the drugs through their corresponding lab tests and lab results (e.g.
kalemia for potassium) and also part of the context of the clinical status of the
patient (actual lab values, but also diseases and other pathologies that are identified
as potential causes of the ADE e.g. renal insufficiency and potassium). We show
that making the system able to catch the monitoring and clinical contexts opens
interesting opportunities for the design of the CDS information content and display
mode. Implementing this model would allow the CDSS to take into account the
actions already engaged by the healthcare team and to adapt the information
delivered to the monitoring and clinical context, thus making the CDSS a partner
to the clinicians, nurses and pharmacists.
Keywords. Computerized decision support systems, clinical decision support,
human factors engineering, adverse drug events, system design
1 Corresponding Author: romaric.marcilly@univ-lille2.fr
Patient Safety Informatics
V. Koutkias et al. (Eds.)
IOS Press, 2011
© 2011 The authors and IOS Press. All rights reserved.
doi:10.3233/978-1-60750-740-6-84
84
Introduction
Adverse Drug Events (ADE) are the most common Adverse Events occurring during
the care process [1]. These ADEs result in human costs in terms of patients’ deaths or
injuries and economic costs in terms of hospital prolonged stays or lawsuits. Therefore,
many countries consider ADEs to be a major public health issue and currently invest a
lot of resources in patient safety programs aiming at identifying, characterizing and
preventing ADEs. One way among many to prevent ADEs is to implement medication
related Clinical Decision Support (CDS) functions, usually integrated in or interfaced
with Computerized Physicians Order Entry applications (CPOE). These systems
support physicians’ therapeutic decision by checking the orders against a medication
knowledge base providing alerts or suggestions to the prescribers. As a result,
physicians can adjust their decision according to the known side effects of the drugs,
their interactions and potential contra-indications. Kuperman et al. [2] identify two
categories of medication CDS. Basic CDS includes drug-allergy checking, basic dosing
guidance, formulary decision support, duplicate therapy checking, and drug–drug
interaction checking, while advanced CDS includes dosing support for renal
insufficiency and geriatric patients, guidance for medication-related laboratory testing,
drug–disease contraindication checking, and drug–pregnancy checking. Despite some
acceptance and usage problems [3], the implementation and use of medication related
CDSS have been found to be beneficial in improving the quality of clinicians’
prescriptions and reducing medication errors [4-5] and ultimately preventing ADEs [6].
Therefore it seems worth pursuing the efforts in designing and developing acceptable,
user centred advanced medication CDSS applications.
1. Background
1.1. Scope of the Study
The present study is part of the European project entitled “Patient Safety through
Intelligent Procedures in medication-PSIP”. The first goal of the PSIP project is to
automatically generate knowledge about ADEs, therefore providing reliable numbers
about ADEs per country, region, hospital or medical unit, describing their type,
consequences and probable causes. This knowledge about ADEs helps identify
situations at risk in each context of care, depending on the patients’ characteristics, i.e.
medical history and current symptoms, and on the care place, for instance the type of
hospital / medical specialty. The second goal of the PSIP project is to deliver to the
healthcare professionals and to the patients who find themselves in these risky
situations, the contextual knowledge that can help them characterize the problem and
adapt the treatment to avoid potential ADEs.
PSIP addresses a particular subset of preventable ADEs, which according to the
NCCMERP taxonomy [7] may be characterized as “medication monitoring errors”,
with a specific focus on faulty monitoring of clinical or laboratory values. As a
consequence the advanced CDS functions developed in PSIP result mainly in Drug-
Laboratory alerts and Drug-Condition/Disease/Age alerts.
The project adopts a user centred / user driven approach to the design of these CDS
functions and to their integration into different EHR (Electronic Health Record) /
R. Marcilly et al. / Medication Related Computerized Decision Support System (CDSS) 85
CPOE systems, so that the resulting CDSS corresponds to the users needs and fits
clinical workflows and cognitive processes.
1.2. Human Factors Limitations of Current Medication CDSS
In spite of their known positive impact, medication CDSS applications remain difficult
to implement and face acceptance problems [3, 8]. These difficulties are due to a
combination of human factors related drawbacks of current systems.
The major drawback of existing systems is undoubtedly their poor signal-to-noise
ratio [9-10]. This problem generates a well known “over-alerting” syndrome due to too
many false positives which in turn engenders “alert fatigue” for the prescribing
physicians. Alert fatigue is “the mental state that is the result of too many alerts
consuming time and energy” [9]. Moreover, the fact that a number of “alerts” are
clinically irrelevant [11] diminishes the clinicians’ confidence in the system. Reducing
over-alerting is therefore one of the major challenges for the design of a medication
CDSS. This question points at the quality and the completeness of the knowledge
implemented in the knowledge base of the medication CDSS and at its ability to catch
and take into account the clinical context of the patient at hand. The PSIP system partly
addresses this issue by contextualizing the alerts depending on the probability of
occurrence of the ADEs per hospital, per clinical unit or medical specialty [12].
However, it is unreasonable to think that a CDSS might incorporate a “perfect” (i.e.
accurate and exhaustive) knowledge so that it would be able to identify and take into
account all relevant characteristics of the clinical case at hand and eradicate the over
alerting. Ultimately, only the clinician is able to gather the relevant clinical
information, assess it and finally make the therapeutic decision. Therefore, no
medication CDSS will ever be “perfect” enough so as to act as a substitute to the
clinicians and fully automate the therapeutic decision making. As a consequence, it is
necessary that the CDS functions support and not replace the clinician’s decision and
act as a partner to her/his medical reasoning and decision making cognitive process.
The second drawback of many existing systems is their poor usability [ 13]. On a
fundamental level, the model of work and the model of clinicians’ reasoning
incorporated in the systems are often inadequate. This usability weakness issues
“compatibility” problems defined as a lack of match between users’ and task
characteristics on the one hand, and the organisation of the output, input, and dialogue
for a given application, on the other hand [14]. As a consequence, alerts are too often
disruptive of the clinical workflows and of the cognitive processes inherent to
medication decision making and monitoring, due to wrong timing, wrong display mode
and wrong/weak content of the information delivered. For example, it is not wise to
suggest to the physician an action s/he is just about to carry out [15], or to alert him/her
on a potentially dangerous situation for which s/he has just taken action by ordering the
corresponding lab tests. All physicians dislike such alerts which they find unnerving.
Moreover, most of the systems fail to make available upon request short or extended
versions of the scientific justifications of the CDS recommendations, which are
necessary to allow the physicians properly assessing their clinical relevance and the
resulting cost-benefit of the medication order for the patient under consideration.
Given the nature of the difficulties and usability issues, a Human Factors
Engineering [16] approach to the design of advanced medication CDS functions would
help solve a part of those problems and contribute to the design of applications acting
as effective and reliable clinicians partners.
R. Marcilly et al. / Medication Related Computerized Decision Support System (CDSS)86
1.3. The Human Factors Engineering (HFE) Approach to the Design of Advanced
Medication CDS Functions
A Human Factors Engineering approach to healthcare work systems aims at optimizing
the relationships between the users, their tasks and the technologies they use to carry
out these tasks in various work environments and organizations. It requires a user-
centred approach to the design of the IT applications, taking into account the needs,
expectations and characteristics of the end users, who need to be actually involved in
the design process. This approach would help design effective and usable medication
CDSS. The most important phase in the HFE approach is the initial one, i.e. the
observation, analysis and modelling of the existing work system. It is therefore
important to retrieve and use the knowledge on the work system accumulated in
previous HF studies on the medication use process in hospital settings [17-18]. These
studies have already provided valuable insights on the intangible characteristics of the
clinical workflows and of the healthcare professionals’ decision making process. The
results emphasize the fact that therapeutic decision making is a dynamic process [19]:
the patient’s condition evolves depending on the healthcare professionals’ actions but
also spontaneously by itself. At each encounter with the patient, clinicians have to
update their knowledge about the patient’s status and his/her evolution, especially as
regards new important elements in the situation, e.g. new lab results or unexpected
clinical evolution of the patient [20]. Moreover, the medication use process is
characterized as a complex distributed work situation: the information is distributed
across the minds of the members of the clinical team but also across physical media,
such as the EHR, the CPOE or the CDSS [21]. These disparate pieces of information
should then be integrated, completed, and interpreted. From the users’ point of view,
the collection, documentation, communication, and retrieval of information are critical
activities.
In the present study, we elaborated on this existing knowledge and completed
previous field studies and analyses by focused observations and modelling of the
monitoring process of patients’ therapeutic treatments based mainly on corresponding
lab values. The objectives of this research are to:
Identify the relevant indicators of the context of lab values based monitoring
of the drug,
identify the relevant indicators of the context of the clinical status of the
patients that may have an impact on the considered ADE, i.e. actual lab values
and eventually other diseases inferred from lab results such as renal
insufficiency, and
elaborate a model supporting the implementation in the CDSS of functions
able to reflect these clinical and monitoring contexts.
2. Methods
2.1. Study Site
The study took place in a 416-bed hospital, the Hospital Center of Denain in northern
France. The hospital has a Patient Care Information system (PCIS), the commercial
product DxCare® from the MEDASYS Company. It includes an EHR equipped with a
R. Marcilly et al. / Medication Related Computerized Decision Support System (CDSS) 87
CPOE which in this version has very limited CDS functions (e.g. alerts in case of
duplicates). The PCIS is interfaced with a pharmacy system, which allows the
pharmacists to check the medication orders and send physicians alerts when they
suspect improper orders. The analyses were carried out in two medicine departments:
the “cardiology” department (medicine A) and the “internal medicine and infectious
diseases” department (medicine B).
2.2. HFE Methods
2.2.1. On Site Observations and Interviews
Over a period of one month (May-June 2009), four HF experts observed all tasks
related to the medication process carried out by 4 physicians, 6 nurses, 2 pharmacists
and 2 assistant pharmacists, with a special focus on all actions related to lab values
monitoring. Observation time amounted to 53 hours and concerned 101 different
patients. Observations were completed with debriefings and semi-structured interviews
to clarify actors’ goals, thought processes and information needs while monitoring lab
values and patients’ treatments. Detailed description of methods can be found in [22].
2.2.2. Structured Analysis of Data and Modelling
We used the SHEL (Software, Hardware, Environment & Liveware) formalism to
describe the data collected. Originally developed for the aviation domain [23], SHEL
aims at representing working contexts and main actors while specifically identifying
existing barriers against errors. It enables a structured description of the work system
and provides an appropriate classification of human errors potentially leading to ADEs.
Given the objective of the project, i.e. to design medication CDS functions, this
formalism is particularly appropriate because it helps designing a system enhancing
and completing existing barriers thus acting as a professional’s partner.
We also used Unified Modelling Language (UML) to express the HF
recommendations as this language has been shown to facilitate the dialogue between
HF experts and computer scientists (designers and developers) [24].
3. Results
3.1. Results of the Analysis of the Work Situation
The analysis of the data collected during the field observations issued twelve SHEL
descriptions of the various tasks performed by all actors during the medication use
process or related to it. For illustration purposes Figure 1 provides a SHEL overview of
the survey by the physicians of the patient therapeutic treatment during the daily
medical round, focused on information gathering activities.
Once the main SHEL elements have been identified, it is possible to describe the
interactions between the four dimensions, in order to get a full picture of the work
system. SHEL also allows identifying existing barriers to errors. For the example
described above, barriers would help the physician not to overlook important
information that should be taken into account to adapt the patient’s treatment.
R. Marcilly et al. / Medication Related Computerized Decision Support System (CDSS)88
Survey by the physicians of the
patient therapeutic treatment
during the daily medical round,
focused on information
gathering activities.
The main objective of the physician is to retrieve
and check all new relevant information or data
about the patient:
•Look for recent data in the patient’s record, i.e.
data received after the last encounter with this
patient or after the last check of the patient’s data.
•Check nurses’transmissions and/or ask them about
the recent patients’clinical evolutions
•Carry out clinical interview and clinical exam of
the patient
S
OFTWARE
[work procedures]
•EHR and CPOE (description of available screens
and their information content)
•Paper documents (e.g. received faxes, or letters,
post-its or informal written notes, etc.)
•Fax
•Telephone
H
ARDWARE
[tools supporting the activities]
•Corridor
•Patient room
•Nursing room
E
NVIRONMENT
[locations where the actions take place]
•Clinicians
•Nurses
•Patient
•Laboratory people
•Pharmacist
L
IVEWARE
[people interacting for this particular task]
Survey by the physicians of the
patient therapeutic treatment
during the daily medical round,
focused on information
gathering activities.
The main objective of the physician is to retrieve
and check all new relevant information or data
about the patient:
•Look for recent data in the patient’s record, i.e.
data received after the last encounter with this
patient or after the last check of the patient’s data.
•Check nurses’transmissions and/or ask them about
the recent patients’clinical evolutions
•Carry out clinical interview and clinical exam of
the patient
S
OFTWARE
[work procedures]
•EHR and CPOE (description of available screens
and their information content)
•Paper documents (e.g. received faxes, or letters,
post-its or informal written notes, etc.)
•Fax
•Telephone
H
ARDWARE
[tools supporting the activities]
•Corridor
•Patient room
•Nursing room
E
NVIRONMENT
[locations where the actions take place]
•Clinicians
•Nurses
•Patient
•Laboratory people
•Pharmacist
L
IVEWARE
[people interacting for this particular task]
Figure 1. SHEL overview of the work situation - survey of the patient therapeutic treatment during the daily
medical round.
Examples of such barriers are:
Doctor-nurse communications and nurses’ reminders to physicians
Phone calls or faxes from the laboratory in case of abnormal results. Those
calls are usually received by nurses who then pass on the information to the
physicians
CPOE alerts on new available lab results, i.e. results that have not been yet
acknowledged by a clinician
Patients’ complains
The analysis highlights the close intertwinement between the medications’ use
process and the laboratory ordering and reporting cycle. The dependency between the
drugs administered to the patient and the biological indicator of their effect (i.e. the lab
test result) is time dependant and strongly impacts the work procedures of the nurses
and physicians:
Lab results must be retrieved on time for the physician to be able to decide
how best to adapt the treatment to the patient’s condition.
For certain drugs (e.g. anticoagulant VKA – Vitamine K Antagonist) nurses
need to check the last corresponding lab values (e.g. INR-International
Normalized Ratio) before administration. When this information is missing,
nurses may have to take initiatives such as taking a new sample of blood and
ask for urgent results, ordering reconciliation being performed later by the
physician in the CPOE system.
The patient’s state evolving as a result of the medications’ effect but also on
its own, the lab results are valid only for a given time period. This period
R. Marcilly et al. / Medication Related Computerized Decision Support System (CDSS) 89
depends on the type of medication whose effect must be monitored and also
on the patient’s conditions. Once the validity period elapsed, the lab test must
be re-ordered to get a new (valid) lab result.
The analysis also identifies the fundamental steps through which a healthcare
professional goes when s/he relies on lab values to monitor the impact of a drug:
Check whether the lab result is available or not:
o In case the lab result is not available: check whether the corresponding lab
test is ordered or not
When the lab result is available, check whether it is recent enough to be valid
or not:
o In case the result is not recent enough, check whether the corresponding
lab order has been renewed or not
When the lab result is available, check whether it is normal (within acceptable
limits) or not:
o In case of abnormal results, consider adapting the treatment (modifying
the drug prescription / administration)
3.2. Characterization of the Monitoring and Clinical Context
Relying on the analysis of the work situation and more specifically on the sequence of
actions carried out by healthcare professionals when checking lab values for a given
drug, we identified typical situations characterizing the current status of drug
monitoring. These situations result form the combination of the status of the lab tests
orders on the one hand and the validity and normality of the available lab values on the
other hand. For each typical situation we can identify whether the monitoring
procedure is appropriate or not, and whether the patient’s clinical status, assessed by
the lab value, is alarming or not (yet). Therefore, these situations characterize the lab
value-based monitoring context and a part of the clinical context for the patient under
consideration.
Figure 2 presents the UML model of the classification process to be performed by
the Contextualized Computerized Decision Support System (Cx-CDSS), leading to the
identification of the monitoring and clinical context for the patients identified by the
system as being at risk of an ADE.
For example, Context 3 corresponds to a situation under control: the drug is
properly monitored because the required lab values are available and recent enough to
be considered valid indicators of the patient’s clinical status, and these lab results are in
normal range.
On the contrary, Context 2 corresponds to a situation which is not properly
monitored, because the required lab values are not available and the system cannot find
any corresponding lab test order.
Context 7 is perhaps even more alarming as the system can identify that the last
available lab value was abnormal, but this value is not recent enough to be considered a
valid indicator of the current patient’s clinical state, and the corresponding lab test
order has not been renewed. In this context, the probability of appearance of the
potential ADE is higher but the effect is not likely to be prevented as it is not properly
monitored.
R. Marcilly et al. / Medication Related Computerized Decision Support System (CDSS)90
Figure 2. UML model supporting the classification of the situations leading to the identification of the eight
relevant monitoring and clinical contexts.
3.3. Recommendations for the Design of the CDS Information Delivered to Healthcare
Professionals
Making the system able to catch the monitoring and clinical contexts opens interesting
opportunities for the design of the CDS information content and display mode.
It is for instance possible to group the contexts in terms of urgency of the situations
and to reflect this degree of urgency in the display mode of the CDS information. All
contexts for which the last lab result available is abnormal (i.e. contexts 6, 7 and 8)
should be considered a priority and given a high “urgency” indicator. Contexts 2 and 4
correspond to situations that are not properly monitored but where no alarming results
have been received yet. For these contexts the information delivered by the CDSS
should be given a medium “urgency” indicator. Finally, contexts 1, 3 and 5 correspond
to situations that are properly monitored because the lab tests have been ordered and
when these lab results are available they are not (yet) abnormal. Therefore, the
information delivered in these situations should be given a low “urgency” rating. The
designers may choose the most appropriate way of indicating the “urgency” rating in
the Human Computer Interface, depending for example on the design chart of the
application (CPOE, EHR) in which the system is integrated.
R. Marcilly et al. / Medication Related Computerized Decision Support System (CDSS) 91
It is also possible to adapt the content of the information delivered to the clinicians
depending on the context. It is recommended that the CDSS not only displays an alert
but also makes suggestions [2]. In contexts 2, 4 and 7 corresponding to situations that
are not properly monitored, and in addition to the display of the rule leading to the
identification of the case as being at risk of ADE, the CDSS could suggest that the
clinician orders the required lab test and eventually propose a short cut to the lab tests
ordering page. On the contrary context 6, in which a new (recent and valid) lab value
came in abnormal, the system could alert the physician on the increasing negative side
effect of the drug and invite him/her to reassess the cost benefit ratio of the
incriminated drug(s).
Finally advanced parameterization functions based on the identification of the
context could be offered to clinicians, pharmacists and nurses to let them upgrade the
level of urgency if needed for specific ADEs, or to take advantage of the monitoring
protocols adopted in the department
4. Discussion
Making a CDSS able to catch elements of the clinical context is highly desirable goal.
The model proposed in this paper is operational and seems simple enough to be
implemented in any medication CDSS integrated in a CPOE or an EHR. However it
requires the incorporation in the system of specific knowledge, as is illustrated in the
case below.
Example: a patient is identified by the PSIP system by triggering the following
rule:
CDSS rule b011: vitKantagonist + cephalosporin Æ high_inr;
Text of the rule for the physician: “An increased effect of the oral
anticoagulant can occur in an infectious context. Cephalosporins by
themselves may increase hemorrhagic risk. Ref.: Thesaurus AFSSAPS 2009”.
In this case the characterization of the monitoring and clinical context would
require the following knowledge to be integrated in the system.
4.1. Identify the Targeted Lab Value
The system has to know what the targeted lab value is for this ADE risk. This
knowledge may be retrieved from the rule itself, i.e. INR (International Normalized
Ratio). However, although international guidelines recommend monitoring VKA
(Vitamin K Antagonist) effect through INR, a number of physicians / laboratories /
hospital departments still rely on other lab values such as aPTT (activated Partial
Thromboplastin Time). This knowledge has to be incorporated to improve the accuracy
of the system and make it able to check for alternative lab tests / values when the
search for INR fails.
4.2. Assess the Lab Value Normality
The system has to know whether the retrieved INR values are “normal” or not. This
knowledge is usually available in the Laboratory Information System as results are
delivered along with normality thresholds and special marks for abnormal results.
R. Marcilly et al. / Medication Related Computerized Decision Support System (CDSS)92
4.3. Assess the Lab Value Validity
Finally, the system has to know whether the last available INR value is recent enough
to be considered valid. The knowledge necessary to answer this question is more
complex. For example, chronic patients who have long been on VKA and are stabilized
do not require frequent monitoring (once every two weeks or once a month). But as
soon as the clinical status changes (e.g. infection), or if a new drug is introduced, a
closer monitoring is required, and this is often the case for hospitalized patient.
Similarly, when the VKA treatment is first introduced, a close monitoring is required
until the patient is stabilized. By default, it is usually recommended to test the INR
every 2 days, and this corresponds to the most common VKA monitoring protocol in
hospital departments. This simple, by default knowledge, could be used by the system.
Ultimately a more elaborated knowledge based on the drug’s pharmacodynamics
(elimination half-life of the product) would be more accurate and allow adaptation to
the type of VKA actually prescribed.
This example shows that a basic, operational knowledge based on by default
values and protocols running in the hospitals could be used to support the
characterization of the monitoring and clinical context of patients at risk of ADE. But
further research could progressively elaborate a more accurate and sophisticated
knowledge, therefore improving the efficiency and accuracy of the system.
5. Conclusion
The characterization of the monitoring and clinical context and the advanced functions
they make possible are not currently available in medication related CDSS. Their
implementation would allow the system to take into account the actions already
engaged by the healthcare team and to adapt the information delivered to the
monitoring and clinical context thus making the CDSS a partner to the clinicians,
nurses and pharmacists. They would also probably lessen the burden of over alerting by
allowing the clinicians to identify at a glance the urgency and type of problem
addressed by the alerts.
Acknowledgments
The research leading to these results has received funding from the
European Community’s Seventh Framework Programme
(FP7/2007-2013) under grant agreement n° 216130 – the PSIP
project.
References
[1] Committee on Identifying Medication Errors, Preventing Medication Errors: Quality Chasm Series,
National Academies Press, 2006.
[2] G.J. Kuperman et al., Medication-related clinical decision support in computerized provider order entry
systems: a review, J Am Med Inform Assoc 14 (2007), 29–40.
[3] R. Koppel, D.A. Kreda, Healthcare IT usability and suitability for clinical needs: challenges of design,
workflow, and contractual relations, Stud Health Technol Inform 157 (2010), 7–14.
R. Marcilly et al. / Medication Related Computerized Decision Support System (CDSS) 93
[4] D.C. Classen, S.L. Pestotnik, R.S. Evans, J.P. Burke, Computerized surveillance of adverse drug events
in hospital patients, Qual Saf Health Care 14 (2005), 221–5.
[5] P.M. Kilbridge, U.C. Campbell, H.B. Cozart, M.G. Mojarrad. Automated surveillance for adverse drug
events at a community hospital and an academic medical center, J Am Med Inform Assoc 13 (2006),
372–7.
[6] E. Ammenwerth, P. Schnell-Inderst, C. Machan, U. Siebert, The effect of electronic prescribing on
medication errors and adverse drug events: a systematic review, J Am Med Inform Assoc 15 (2008),
585–600.
[7] National Coordinating Council for Medication Error Reporting and Prevention, NCC MERP: The First
Ten Years "Defining the Problem and Developing Solutions", Available at: http://www.nccmerp.org/,
last access on March 2011.
[8] E. Ammenwerth et al., Impact of CPOE on mortality rates--contradictory findings, important messages,
Methods Inf Med 45 (2006), 586–93.
[9] S.H. van der Sijs, J. Aarts, A. Vulto, M. Berg, Overriding of drug safety alerts in computerized
physician order entry, J Am Med Inform Assoc 13 (2006), 138–47.
[10] J.F. Peterson, D.W. Bates, Preventable medication errors: identifying and eliminating serious drug
interactions, J Am Pharm Assoc 41 (2001), 159–60.
[11] S.M. Handler et al., A systematic review of the performance characteristics of clinical event monitor
signals used to detect adverse drug events in the hospital setting, J Am Med Inform Assoc 14 (2007),
451–8.
[12] E. Chazard, G. Ficheur, B. Merlin, M. Genin, C. Preda, PSIP consortium, R. Beuscart, Detection of
adverse drug events detection: data aggregation and data mining, Stud Health Technol Inform 148
(2009), 75–84.
[13] R. Khajouei, M.W. Jaspers, The impact of CPOE medication systems’ design aspects on usability,
workflow and medication orders: a systematic review, Methods Inf Med 49 (2010), 3–19.
[14] J.M.C. Bastien, D. Scapin, Ergonomic criteria for the evaluation of human-computer interfaces, Institut
National de recherche en informatique et en automatique, France, 1993.
[15] R.A. Miller, R.L. Waitman, S. Chen, S.T. Rosenbloom, The anatomy of decision support during
inpatient care provider order entry (CPOE): empirical observations from a decade of CPOE experience
at Vanderbilt, J Biomed Inform 38 (2005), 469–85.
[16] M.C. Beuscart-Zéphir, P. Elkin, S. Pelayo, R. Beuscart, The human factors engineering approach to
biomedical informatics projects: state of the art, results, benefits and challenges, Yearb Med Inform
(2007), 159–77.
[17] M.C. Beuscart-Zephir et al., Impact of CPOE on doctor-nurse cooperation for the medication ordering
and administration process, Int J Med Inform 74 (2005), 629–41.
[18] M.C. Beuscart-Zephir, S. Pelayo, F. Anceaux, D. Maxwell, S. Guerlinger, Cognitive analysis of
physicians and nurses cooperation in the medication ordering and administration process, Int J Med
Inform 76 (2007), S65–77.
[19] M.C. Beuscart-Zephir, S. Pelayo, S. Bernonville, Example of a human factors engineering approach to
a medication administration work system: potential impact on patient safety, Int J Med Inform 79
(2010), e43–57.
[20] S. Pelayo, M.C. Beuscart-Zéphir, Organizational considerations for the implementation of a
computerized physician order entry, Stud Health Technol Inform 157 (2010), 112–7.
[21] T. Cohen, B. Blatter, C. Almeida, E. Shortliffe, V. Patel, A cognitive blueprint of collaboration in
context: Distributed cognition in the psychiatric emergency department, Artif Intell Med 37 (2006), 73–
83.
[22] C. Riccioli, N. Leroy, S. Pelayo, The PSIP approach to account for human factors in adverse drug
events: preliminary field studies, Stud Health Technol Inform 148 (2009), 197–205.
[23] F.H. Hawkins, Human Factors in Flight, Aldershot, UK, Gower, 1987.
[24] S. Bernonville, C. Kolski, N. Leroy, M.C. Beuscart-Zephir, Integrating the SE and HCI models in the
human factors engineering cycle f or re-engineering Computerized Physician Order Entry systems for
medications: basic principles illustrated by a case study, Int J Med Inform 79 (2010), 35–42.
R. Marcilly et al. / Medication Related Computerized Decision Support System (CDSS)94
