A Business Rules Design Framework
for a Pharmaceutical Validation and
Alert System
A. Boussadi1, 3; C. Bousquet1, 2; B. Sabatier3; T. Caruba3; P. Durieux1, 3; P. Degoulet1, 3
1Université Paris Descartes (Paris 5), Paris, France and laboratoire de recherche en ingénierie des connaissances
et e-santé (INSERM UMR_S 872, Eq 20), Paris, France;
2University of Saint Etienne, Department of Public Health and Medical Informatics, St.-Etienne, France; 3Georges Pompidou University Hospital (HEGP), Paris, France
Keywords
Computer-assisted decision making, decision support systems, clinical organization and ad-ministration, drug therapy, computer-assisted organization and administration
Summary
Objectives: Several alert systems have been developed to improve the patient safety as-pects of clinical information systems (CIS). Most studies have focused on the evaluation of these systems, with little information provided about the methodology leading to system im-plementation. We propose here an ‘agile’ busi-ness rule design framework (BRDF) supporting both the design of alerts for the validation of drug prescriptions and the incorporation of the end user into the design process.
Methods: We analyzed the unified process (UP) design life cycle and defined the activ-ities, subactivactiv-ities, actors and UML artifacts that could be used to enhance the agility of the proposed framework. We then applied the
Methods Inf Med 2011; 50: 36–50 doi: 10.3414/ME09-01-0074 received: August 20, 2009 accepted: August 27, 2010 prepublished: October 20, 2010 Correspondence to: Abdelali Boussadi
Laboratoire de recherche en ingénierie des connais -sances et e-santé (INSERM UMR_S 872, Eq 20) 15 rue de l’école de médecine
75006 Paris France
E-mail: abdel.boussadi@spim.jussieu.fr
proposed framework to two different sets of data in the context of the Georges Pompidou University Hospital (HEGP) CIS.
Results: We introduced two new subactivities into UP: business rule specification and busi-ness rule instantiation activity. The pharmacist made an effective contribution to five of the eight BRDF design activities. Validation of the two new subactivities was effected in the con-text of drug dosage adaption to the patients’ clinical and biological contexts. Pilot experi-ment shows that business rules modeled with BRDF and implemented as an alert system triggered an alert for 5824 of the 71,413 pre-scriptions considered (8.16%).
Conclusion: A business rule design frame-work approach meets one of the strategic ob-jectives for decision support design by taking into account three important criteria posing a particular challenge to system designers: 1) business processes, 2) knowledge model-ing of the context of application, and 3) the agility of the various design steps.
1. Introduction
Many studies dealing with drug prescrip-tion errors have provided support for the use of clinical decision support systems (CDSS) within computerized physician or -der entry (CPOE) systems [1–4]. However, studies evaluating CPOE and CDSS have
frequently reported a reluctance of physi -cians to use the computerized tools [5]. Bhosle et al. [5] suggested pharmacists may be more willing to use validation systems than physicians. Pharmacists are likely to prevent adverse drug events (ADE) effi-ciently [6], thereby decreasing the costs as-sociated with these errors [7]. Leape et al.
[8] estimated the impact on the frequency of ADE of the changes introduced by phar-macists. They reported a frequency of 10.4 ADE per 1000 patient-days before the intervention of pharmacists and 3.5 ADE per 1000 patient-days after the intervention of pharmacists (p < 0.001). However, this would require the intervention of pharma-cists very early in the drug delivery loop.
In France, pharmaceutical validation has been mandatory since 1991 [9, 10] and needs to be integrated into the drug pre-scription delivery loop. In a computerized environment, pharmaceutical validation involves an analysis of the physicians’ drug prescriptions entered with a CPOE to de-tect the possible errors (씰Fig. 1). Pharma-cists have to verify the appropriate set of data stored into the electronic medical record (EMR) and make use, as well as physicians, of an appropriate decision sup-port system (CDSS). If the prescription is deemed dangerous for the patient, the pharmacist adds a warning into the EMR/ CPOE, and eventually communicates/tele-phones with the prescriber to discuss pro-posed changes in the prescription. Two bar-riers must be recognized to comply with the current regulation. First, it is difficult to apply this process to prescriptions that are not entered through a CPOE. Second, in situations in which the EHR /CPOE pro-vide ready access to all drug orders, the daily validation of these orders requires a large bulk of work by pharmacists and may therefore not be cost-effective [11].
A CDSS adapted to pharmaceutical validation could potentially make the valida -tion activities of pharmacists more efficient; reduce communications with physi -cians, and thereby potentially increasing prescription safety at a reasonable cost and with an acceptable workload for
pharma-cists. DoseChecker [12] is an example of expert system developed for pharmacists, providing alerts and allowing pharmacists to check the doses of the drugs prescribed. Pharmacists contacted physicians about 41% of DoseChecker system alerts and physicians accepted 75% of the pharma-cists’ recommendations. Mullet et al. [13] modified an existing computerized deci-sion support system dealing with doses of anti-infection drugs intended for adults for use in an academic pediatric intensive care unit and measured the impact of this new system on medication-related outcomes. They reported a 59% decrease in the num -ber of pharmacist interventions required due to the administration of erroneous drug doses. In their study, as in most pub-lished studies on alert systems, Mullet et al. [13] focused on evaluation of the system but provided little information about the methodology leading to system implemen-tation.
One of the general conclusions of a re-port published by the Agency for Health-care Research and Quality (AHRQ) of the US Department of Health & Human Services was that the generalization of knowl -edge concerning the types of health infor-mation technologies (HIT) available and their methods of implementation would be very useful for health organizations, over-coming current limitations to the wide-spread implementation of HIT [14]. Phar-maco-informatics specialists have sug-gested that clinical pharmacists should play a key role in the management of medi-cation-associated knowledge, and in the design and implementation of CPOE sys-tems [15]. Kuperman et al. [16] reviewed the common categories of medication-related CDS within CPOE and defined several questions for facilitating the classi -fication of these categories:
● How does it work?
● What is the potential benefit?
● What (if any) are the results of studies
that have documented the benefits and/ or undesirable side effects?
● Which issues (e.g., knowledge-base
management, user interface issues) cur-rently prevent maximal benefit?
● What steps might facilitate further
de-velopment of the specific category of decision support?
He then defines two main categories of decision rules associated with the execu-tion of a CDSS: basic and advanced deci-sion rules. Basic CDS are more straightfor-ward than advanced CDS and it has been suggested that advanced CDS should be implemented only after the basic decision support is in place.
Different CDSS development strategies have been adopted [17]. They depend on the hospital and clinical culture within which they are deployed, and even within an organization, differed specialties may have different cultures. One of these strat-egies is based on the implementation of alerts that have already been shown to be effective: alerts for drug dosage adaptation, with the progressive addition of other types of alerts such as alerts concerning allergies or drug-disease interactions.
In summary, the design and implemen-tation processes have both a social and a technical dimension [18, 19]. System de-signers and developers must therefore understand the organizational dynamics (business process modeling) and relate them to the technical aspects (design pro-cess management). The implemented sys-tem must respond to the user’s require-ments, but the user must also adapt to the changes resulting from the introduction of
the system. Experts in software design methods speak in this context of ‘agile’ soft-ware development methods. ‘Agile’ develop-ment methods aim to ease the planning of software development, to facilitate changes and to increase the involvement of end users in the software design cycle, to maximize comprehension of the user’s needs [20].
There are several formalisms for the modeling of business processes and user requirements, the most widespread of which is UML (unified modeling language) [21, 22]. However, it is unclear whether UML use fits into the framework of a de-sign method covering the entire software design cycle (from the feasibility study to maintenance). In business management, approaches such as “Six Sigma” and “Lean” are used to improve product and/or process quality [23, 24]. Davenport [24] has argued that the use of Six Sigma is declining, for various reasons, including its inability to integrate information technology into its implementation. He suggests that ap-proaches developed in software engineer-ing, such as business process engineerengineer-ing, should be used in the future, allowing com-panies to combine process change with the information systems they install. Osheroff et al. [25] proposed a six-step process for the development of CDSS in their CDSS
implementer’s manual. This manual pro vides a useful framework for CDSS de -velopment, with a worksheet for each development step, to determine specific CDSS goals and objectives, to list the infor-mation systems infrastructure available to address the objectives, and to select and specify CDSS interventions as a function of the chosen objectives. However, all the knowledge collected on these worksheets must be translated into a modeling lan-guage, and this step is not clearly explained in the manual.
The authors of the UML recommend the use of approaches developed in soft-ware engineering, such as the unified pro-cess (UP), to cover all steps relating to the life cycle of the software [26]. The unified process is applied worldwide combining the various best practices that have evolved over the years [27]. It may be defined as a ‘generic’ design process that can be adapted to the design of a broad range of software systems and is appropriate for different skill levels and project sizes [26]. UP man-ages the design process through inception, elaboration, construction, and transition phases [26]. Each phase comprises several activities (requirements, analysis, etc.), the importance of which depends on the con-text of application and the phase of the project. UP defines business process mod -eling as an activity in its design life cycle and allows the end user to become involved in this activity, through the use of business use cases.
In parallel, different languages have been proposed for the modeling of clinical practice guidelines [28]. Approaches im-plementing these languages can be used to produce decision rules from clinical guide-lines such as the Arden syntax, GELLO [29], Asbru [30], EON [31], GLIF [32], or Proforma [33]. However, due to the com-plexity and ambiguity of most clinical practice guidelines [17, 34], it remains a daunting enterprise to convert them to their formal representation [17]. The com-plexity involved in the use of these ap-proaches goes against the ‘agile’ nature of the desired business rules modeling frame-work. Ideally, the selected formalism should be articulated with the design pro-cess to minimize the complexity of writing and reading for the user. This should make
it possible to include users in the process of business rule design, adapt the system in re-sponse to the users’ requirements, and to determine how the system will change the activities of the business. This is the case in the Semantics of Business Vocabulary and Business Rules (SBVR) formalism [35].
SBVR is a meta-model for the devel-opment of semantic templates, business vocabularies and business rules. It is an ob-ject management group (OMG) standard. SBVR business rules are written with a business object model (BOM). This model is the result of design and analysis activity and is based on the UML class diagram. The SBVR syntax is based on the Inter-national Standards Organization (ISO) standard for the English language; SBVR business rules are therefore expressed in a form very close to natural language and ap-propriate for any business context [35].
We describe here our experience in the adaptation of an existing ‘heavyweight’ modeling method, UP, for the creation and maintenance of business rules for the vali-dation of drug prescriptions and the gener-ation of alerts. This adaptgener-ation of UP takes into account three important criteria pos-ing a particular challenge to system de-signers [18, 19]. Firstly, the developer must identify and model user requirements and the business processes in which the alert system works. Secondly, the developer needs to model the knowledge associated with the decision rules with an appropriate language. Thirdly, the ‘agility’ [20] of soft-ware development must be increased in the various design steps within the proposed framework, to allow users to participate in the design process.
To test the concepts proposed, we have applied our business rule development framework (BRDF) to two different sets of data: 1) data from a business processes study of the pharmaceutical validation ac-tivity at Georges Pompidou European Hos-pital (HEGP), and 2) data from Lindblad’s study [36], to design and maintain business rules for pharmaceutical validation sup-port. Finally, we have implemented and evaluated the performance of the resulting business rules within a commercial busi-ness rule management system (IBM/ILOG JRules®).
2. Materials and Methods
2.1 Adaptation of the UP and Application of the Proposed FrameworkWe analyzed the design life cycle of the UP, with the objective of adapting it to propose an agile framework dedicated to the specifi-cation of decision rules. We aimed to:
● determine, for each phase, the activities,
subactivities, actors and UML artifacts required to achieve the desired objec-tive;
● add new activities to the UP design life
cycle if required, and
● delete any UP activities deemed
un-necessary.
We then applied the framework resulting from this adaptation to the two chosen feasibility studies.
2.2 Feasibility Studies
The first situation to which we applied the proposed framework was the pharmaceuti-cal validation activity of the HEGP central pharmacy. HEGP is an 880-bed teaching hospital specializing in acute care. The HEGP clinical information system (CIS) has four major clinical components: an ad-mission-discharge and transfer, an elec-tronic medical record, and a CPOE compo-nents from Medasys®, and a resource and scheduling system from McKesson/Persé®
[37]. Terms and concepts used by the EMR and CPOE are declared in a common con-cepts dictionary that facilitates their reuse by other components of the CIS. The dic-tionary includes ICD10 and SNOMED 3.5, DRG codes for diagnosis and clinical obser-vations from structured forms (181,297 as of June 2010). The terminology for drugs (31,363 as of June 2010) is imported from the THERIAQUE® data bank [38]. Infor-mation on drug-drug interactions is im-ported from the Vidal® pharmaceutical databank. Terminology for biological con-cept (7291 as of June 2010) in the concon-cept dictionary is local to the HEGP CIS but in the process of migration towards LOINC. HEGP CIS is currently used for every pre-scription of biological or radiological tests,
but for the drug prescriptions for only 331 beds. The workflow organization of the drug prescription analysis activity at HEGP en-ables pharmacists to validate the computer-ized prescriptions, but already re quires four full-time pharmacists. Physi cians enter drug prescriptions directly into Dx-C@re® for validation by pharmacists via the phar -macy interface of the Dx-C@re® CPOE: Valid_Pharma®. Physicians and pharma-cists make use of the same electronic medi-cal record (EMR) management tools. HEGP aims is to achieve CIS use for the drug pre-scriptions for 650 beds in 2011 making necessary the development of a more effi-cient strategy for pharmacy validation.
The choice of the type of decision rule triggering system alerts was based on a combination of the business requirements analysis of the activities of pharmacists in terms of decision support and published recommendations on the subject. We con-ducted a series of interviews with the phar-macists responsible for pharmaceutical validation, to assess their needs. This busi-ness requirements analysis confirmed that several categories of alerts were required: drug dosage adjustment, drug-allergy checking, checking of drug-disease interac-tions and contraindicainterac-tions. Basic decision rules [16], such as checks for duplicate treatment, automatic dose control for oral forms and searches for drug-drug inter-actions, are already available in Dx-C@re®. However, advanced decision rules [16] are not currently implemented in this com-ponent of the CIS. We therefore decided to develop decision rules corresponding to advanced guidelines for medication-associated laboratory testing [16]. This choice was then validated by considering its impact on the workload for the pharma-cists involved in the analysis of prescrip-tions for the 331 beds for which computer-ized drug prescription is currently in oper-ation. Three business rules (BRx) templates were selected for the evaluation:
● BR1: Adaptation of drug dose as a
func-tion of the patient’s glomerular fil-tration rate (GFR)
● BR2: Adaptation of drug dose as a
func-tion of internafunc-tional normalized ratio (INR) and/or anti-Xa activity and the patient’s clinical situation
● BR3: Adaptation of the dose of drugs
causing hyperkalemia as a function of the patient’s potassium levels
The second feasibility study concerned the data presented in Lindblad’s article [36]. This article was chosen because it deals with the development of alerts correspond-ing to the advanced checkcorrespond-ing of disease interactions and contraindications [16]. The authors propose a list of 28 drug-disease interactions in the elderly for which a consensus was reached. The list is pre -sented with diseases on one side and drug conditions on the other: for example, pep-tic ulcer disease + (aspirin/non-aspirin non-steroidal anti-inflammatory drugs (NSAIDs)) and patient over the age of 65.
Business rules were then instantiated from the business object model resulting from the design stage of our framework. For completion of the data structure, this model must be mapped onto a generic model [39]. We used the Séné model [39], a generic model for drug prescription, for this pur-pose. Séné’s drug prescription model is based on an object-oriented formalism dif-ferent from the UML: Coad-Yourdon for-malism. It was therefore nec essary to define rules for mapping Coad-Yourdon graphic elements onto UML graphic elements, to re-write Séné’s model in UML. We also modi-fied the generic structure of Séné’s model to ensure that it complied with the constraints of our application [40].
The business rules resulting from the two applications studied in this experi ment were implemented with IBM/ILOG JRules®. This process begins with the implementation of the execution object mod el (XOM) from which the business rules are implemented. The execution object model corresponds to a UML class diagram. The execution object model maps a Java class to each class of the business object model and a Java attribute to each business object model attribute. The execution object model may be constructed from compiled Java classes (Java XOM), XML diagrams or web services (Dynamic XOM). IBM/ILOG JRules® generates its own business object model from the imple-mented execution object model via a verbal-ization process. This process attaches natu-ral-language terms and phrases to each class, and users can then employ business object
model methods to write business rules in near-natural language. This made it possible to express our business rules in different ways: as a decision table, textual business rule or decision tree.
Textual business rules consist of com-binations of modifiable building blocks. If the business object model contains an at-tribute “Presentation Name” for the class “Drug”, the corresponding textual business rule will contain two phrases {the Presenta-tion Name} of {a Drug}. Decision trees pro-vide an alternative and more convenient way of viewing and managing large sets of busi-ness rules, especially when these rules are not symmetric. Decision trees make it easier to understand large sets of non-symmetric rules because the path from the first con-dition to the end of the actions along any branch corresponds to one rule. In a decision tree rule, the attribute “Presentation Name” and the class name “Drug” appear as a dia-mond-shaped node. The possible values for the condition are represented by branches and the actions are declared at the end of each branch. Decision tables can also be used to view and manage large sets of similar busi-ness rules. They consist of rows and columns in which each row corresponds to a single rule with, for example, the attribute “Presen-tation Name” and the class name “Drug” as column names de fining the conditions and actions applying to the rules [41].
The order in which the various imple-mented business rules were executed was managed by defining a rule flow for each business rule. A rule flow is a variant of the UML state chart diagram, in which each state includes one or more business rules (actions). Whether a state is executed de-pends on the guard condition of each tran-sition and data entries. A guard condition is generally a Boolean conditional expression governing transitions between two or many states in the diagram. The guard condition is evaluated at the initiation of a transition and, if the guard condition is satisfied, the transition occurs.
Test cases are generated for each written rule pattern, with a wizard provided by IBM/ILOG JRules®. The corresponding source code is edited for the entry of typical conditions of use, such as the name of the drug, age of the patient and potassium level, as input data. The test case is successful if an
alert is triggered in abnormal conditions, such as an inappropriate potas sium level or a low glomerular filtration rate.
3. Results
The activities required to meet our objec-tives for each UP phase, the UML artifacts required and the actors participating in each activity are summarized in 씰Table 1 and described in detail below.
3.1 Business Process Modeling Activity (Activity Number 1, Business Use Case Diagrams)a The UP inception phase begins with the mod eling of business processes [26]. Busi-ness use case diagrams can be used to model the business processes involved in drug prescription validation activity (씰Table 1).
Several adaptations relating to a number of activities, including risk identification and cost estimation, were made in this phase. These activities are not essential to meet the aims of business rules design. We will therefore focus instead on business process mod -eling for the validation of drug prescrip-tions. The modeling of business processes for this activity resulted in the identification of seven actors and two business use cases. The business use case “To validate prescrip-tions” comprised one main scenario and 14 alternative scenarios (씰Fig. 2).
3.2 System Requirements Activity (Activity Number 2, System Use Case Diagrams)a
Requirements are described with system use case diagrams. Business use case mod-els facilitate the development of system use case models [26]. Eight system use cases were identified for improving the phar-maceutical validation interface. Three sys-tem use cases related to the business use case “To validate prescriptions” were iden -tified and are described below (씰Table 1).
3.3 Business Rules Specification Activity (Activity Number 3, System Use Case Diagrams)a
UP does not describe the specification of business rules and the introduction of these rules into the software design life cycle. Our adaptation of the UP elaboration phase therefore involved introducing a new stage BRDF activities Activities described
in the UP approach
Artifacts Actors
1. Business process modeling Yes Business use case diagram (UML) Physician/pharmacist + programmer
2. System requirements Yes System use case diagram (UML) Physician/pharmacist + programmer
3. Business rules specification No System use case diagram (UML) Physician/pharmacist + programmer
4. System requirements analysis Yes Analysis diagram (UML) programmer
5. Design Yes Class diagram (business object model, UML) programmer
6. Business rules instantiation No Class diagram + decision rule formalism Physician/pharmacist + programmer
7. Implementation Yes Rule engine programmer
8. Tests Yes Test cases (UML) Physician/pharmacist + programmer
Table 1 Comparison of UP design activities and the activities of the proposed framework
Fig. 2 Part of sequence diagram corresponding to an alternative scenario of the business use case “To validate prescriptions”
supplementing the determination of re -quirements [42, 43] (씰Table 1). This stage involves initially identifying the business rules with the greatest impact on the pharmacist’s work in the conditions of pharmaceutical validation. We therefore queried the HEGP EMR database to determine the proportion of drug pre -scriptions for each department involved in pharmaceutical validation for which the drugs concerned would trigger an alert (씰Table 2).
The drug prescriptions in the DxCare® CPOE corresponding to the three business rule templates selected for the evaluation accounted for 24.39% (36,478 drug pre-scriptions) of all prescriptions in the de-partments for which pharmaceutical vali-dation was carried out from January 1, 2006 to January 1, 2007 (씰Table 2).
After determining the most important rules, we wrote draft rules corresponding to the business rules BRx templates [42]. These templates should guide the descrip-tion of the corresponding system use cases (previous design stage). According to these business rule templates, we wrote “if then else” rules in the form of decision tables, and then validated these rules with the pharmacists. This made it possible to estab-lish a list of molecules, biological markers and clinical situations for which these rules should trigger alerts.
We described each business rule tem-plate textually in terms of the following items: identification (ID), name, descrip-tion, example, source, linked rule, accord-ing to Ambler’s recommendations [42]. The system use cases attached to each busi-ness rule’s BRx template were as follows:
● System use case: “Validate the
prescrip-tions of patients with renal failure treated with drugs for which dose should be adapted as a function of glomerular fil-tration rate”, consisting of one main sce-nario and eight alternative scesce-narios.
● System use case: “Validate the dose of
anticoagulant drugs as a function of INR and/or anti-Xa activity together with the patient’s clinical situation”, consisting of one main scenario and eight alternative scenarios.
● System use case: “Validate the dose of
drugs causing hyperkalemia as a func-tion of the patient’s potassium levels”,
consisting of one main scenario and nine alternative scenarios.
Each system use case is described by stand -ardized structured tables containing the following items: use case designation, scope, main actor, business workers (sec-ondary actors), triggering event, pre-con-ditions, post-conpre-con-ditions, the main scenario and the different alternative scenarios. Each scenario must be described textually as an interaction between the user of the system (pharmacist) and the system.
The last UP stage of requirement deter-mination is the structuring of the system use case model [26]. The structuring of the system use case activity of the concrete examples of system use cited above gener-ated a new system use case, the abstract use case ‘To validate prescription’ (씰Fig. 3).
For the second feasibility study, we con-sidered the list of 28 drug-disease inter-actions as business rule templates. Follow-ing the same method, we listed the mol-ecules from the HEGP drug booklet cor-responding to the drugs cited in Lindblad’s study. We then wrote “if then else” rules in the form of decision tables, in which each entry corresponded to a disease listed in the table presented in Lindblad’s study (씰Table 3).
3.4 Analysis of System Require-ments Activity (Activity Number 4, Analysis Diagrams)a
The analysis activity of the UP elaboration phase makes use of the description of each
system use case to identify the first drafts of design classes known as analysis classes. The identified analysis classes are used to build the analysis class diagram, constitut-ing the first draft of the business object model. The following analysis classes were identified for pharmaceutical validation activities at HEGP:
● one control class: “Pharmaceutical
Vali-dation Manager”,
● four boundary classes: “Application
Programming Interface Knowledge Base”, “Pharmaceutical Validation Form User Interface”, “System User Interface”, “Application Programming Interface Engine Rule”,
● six entity classes: “Pharmaceutical
Vali-dation Data”, “Laboratory Result”, “Drug”, “Prescription”, “Patient”, and “Message”. Execution of the main scenario of the ab-stract system use case: ‘To validate prescrip-tion’, following the highlighted analysis class, is described through a collaboration diagram (씰Fig. 4). This diagram makes it possible to test the different scenarios of the corresponding system use case.
Our adaptation of the elaboration phase of the UP concerned the impact of the in-troduction of the new ‘Specification Busi-ness Rules’ activity into the UP design life cycle on the ‘System Requirements Analy-sis’ activity. Each analysis diagram (analysis class diagram and analysis collaboration diagram) derived from the ‘System Requirements Analysis’ activity must be linked to a business rule template BRx through the corresponding system use case. Business rules templates (BRx) Drug prescription
Adaptation of drug dose as a function of the pa-tient’s glomerular filtration rate (GFR)
12,032 (8.04%) Adaptation of drug dose as a function of
inter-national normalized ratio (INR) and/or anti-Xa activity and the patient’s clinical situation
13,697 (9.16%)
Adaptation of the dose of drugs causing hyperkale-mia as a function of the patient’s potassium levels
10,749 (7.19%)
Total 36,478 (24.39%)
Others 113,083 (75.61%)
Total number of drug prescriptions 149,561 (100%)
Table 2 Business rules tem-plates identified in the new activity ‘Specification of business rules’ from 1 January 2006 to 1 January 2007
3.5 Design Activity (Activity Number 5, Class Diagram)a
In the design activities of the construction phase of the UP, the first drafts of design classes are identified from the class stereo-types highlighted in the ‘Entities’ analysis during the preceding design stage [26]. These design classes can be used to generate the first draft of the design class diagram. Our adaptation of the UP construction phase concerns the mapping of the design classes diagram onto a generic prescription model to complete its structure [39]. This procedure was much less time-consuming than the multiple iterations required for com-pletion of the business object model. It also made it possible to generate business rules tailored to the pharmacist’s requirements in terms of vocabulary and semantics. The names of certain classes of Séné’s model were changed to comply with our semantic and vo-cabulary model. For exam ple, pharmacists preferred the label ‘Drug’ for the class “Drug Preparation”. Certain relationships between
classes were also modified, such as the rela-tionship between the “Prescription Adminis-tration” and Event classes. We think it is pre-ferable to retain an association between these
two classes because a Drug Administration may have no, one or several trigger events. The same procedure was applied to the relation-ship between the “Prescription
Adminis-Fig. 3
Structuring of system use cases
Conditions Actions
Disease Treatment class (drug) Age Benign prostatic hyperplasia Anticholinergics (excluding tricyclic antidepressants)
≥ 65 The system alerts the pharmacist and provides advice for the pharmacist and the prescriber
Chronic renal failure Nonaspirin NSAIDs ≥ 65 The system alerts the pharmacist and provides advice for the pharmacist and the prescriber
Constipation Anticholinergic drugs
(excluding tricyclic antidepressants)
≥ 65 The system alerts the pharmacist and provides advice for the pharmacist and the prescriber
Tricyclic antidepres-sants
≥ 65 Opioid analgesics ≥ 65
Table 3 Part of a decision table representing an “if then else” rule corresponding to the drug-disease interactions of Lindblad’s study [36]
tration” and “Dosage Regimen Phase” classes. The business object model can easily be mapped onto the classes of the HL7 reference information model (RIM). After download-ing HL7 RIM 2.20 [44], we analyzed the vari-ous HL7 RIM classes and their attributes, to
identify those most similar in terms of their definition, attributes and designation to our information model classes [40, 45]. 씰Table 4 shows the results of this mapping, with the classes in our information model on the left and the HL7 RIM classes required to
repre-sent the data for our model on the right (see
씰Appen dix – Fig. A-1 for more details). In the second feasibility study, we needed to match the business object model with the terms and semantics used in Lind-blad’s study. For example, in 씰Table 3, the condition ‘benign prostatic hyperplasia’ corresponds in our model to an instance of the attribute ‘wording’ of the class ‘Ante -cedent’, whereas the condition ‘age’ cor-responds in our model to an instance of the attribute ‘age’ of the class ‘Patient’. We also adapted some drug-disease interactions as a function of common practice at HEGP. For example, the interaction ‘Dementia-Anticholinergic drugs (excluding tricyclic antidepressants)’ was rejected by the expert pharmacists at HEGP.
3.6 Business Rule Instantiation Activity (Activity Number 6, Class Diagram and Business Rule Formalism)a
Our adaptation of the construction phase was also associated with the introduction of a new activity: ‘Business Rules
Instanti-Fig. 4 Analysis collaboration diagram corresponding to the execution of the main scenario of the abstract system use case ‘To Validate Prescription’
Table 4 The business object model and the equiv-alent classes in the HL7 RIM
Class in business object model Equivalent class in HL7 RIM
Prescription Act / SubstanceAdministration
Drug Entity / Material
LabResult Act / Observation
Patient Role / Patient
Allergy Act / Observation
PharmaceuticalValidationData Act / Observation
Pharmacist Role / Employee
Prescriber Role / Employee
Administration Act / SubstanceAdministration
Event Act / SubstanceAdministration
DosageRegimenPhase Act / SubstanceAdministration
Antecedent Act / Observation
ChronicDisease Act / Observation
Act / Observation AcuteDiseaseAct / Observation
ation’. The instantiation of rules corre -sponding to the business object model requires the identification and naming of relevant relationships between classes. The rules mapping SBVR syntax onto the busi-ness object model [46] are then applied. For example, class name in the business ob-ject model corresponds to concept name in SBVR syntax and class name relationship in the business object model corresponds to the < Role1>Verb < Role2 > ‘Fact type’ in SBVR syntax. This procedure was repeated for each drug presentation name from the list of drugs established with the pharma-cists for each business rule template BRx, taking into account all related active in-gredients.
The rules for mapping SBVR syntax onto the business object model made it possible to instantiate the business rules in their textual form (씰Fig. 5). These rules in-clude:
● 247 business rules for the BR1 template ● 156 business rules for the BR2 template ● 24 business rules for the BR3 template
In the second feasibility study, SBVR rules were instantiated from the table as a func-tion of the business object model, using the mapping rules between SBVR syntactic el-ements and the graphic elel-ements of the business object model.
3.7 Implementation and Testing Activity (Activity Number 7 and 8, Rule Engine Program Language and Test Cases)a
The XOM was implemented in Java to comply with the design class diagram in IBM/ILOG JRules®, generating the cor-responding business object model. The im-plementation of the XOM and the business object model makes it possible to write rules corresponding to all business rules BR1, BR2, and BR3 and the rules derived from Lindblad’s.
3.7.1 System Architecture and Execution Scenario
After several iterations of the design pro-cess, we adopted a system architecture with the following components (씰Fig. 6):
● IBM/ILOG JRules®Rule Studio®
(busi-ness rule development studio): a devel-opment environment allowing to write new rules or to manage changes to exist-ing rules [41].
● IBM/ILOG JRules®Rule Team Server®: a
rule management server and repository with a collaborative and user-friendly web environment allowing pharmacists to write, manage, validate and deploy new or existing rules [41].
● IBM/ILOG JRules®Rule Execution
Server®: a rule execution environment including the Rule Engine and a web ap-plication to manage several execution parameters [41].
● The drug knowledge base from BCB®
(Banque Claude Bernard).
Many studies have highlighted the need to include a commercial drug knowledge base for the development of more efficient deci-sion rules [47]. The includeci-sion of such a knowledge base is also required to antici-pate the extension of the alert system to cat-egories of rules dealing with drug-allergy checking and the checking of drug-disease interactions and contraindications.
씰Figure 6 describes the scenario of an interaction between pharmacists, a pro-grammer and the alert system within the current architecture. The programmer im-plements the business rule templates cor-responding to the BR1 templates in IBM/ ILOG JRules® Rule Studio® and deploys them in the collaborative development component (IBM/ILOG JRules® Rule Team Server®). The pharmacists connect to IBM/ILOG JRules®Rule Team Server®, in-stantiate decision rules from the templates deployed by the programmer, and write decision rules. The programmer can delete, modify, and optimize the decision rules written by the pharmacists, and it may also be necessary to modify the business object model if the pharmacists are unable to find the concepts they consider necessary for the writing of decision rules. This oper-ation is repeated until a consensus is reached between the programmer and the pharmacists on the syntax and semantics of the rules. Finally, the programmer deploys the rules in the IBM/ILOG JRules®Rule Engine® and executes them.
Test cases corresponding to each business rule were successful. The system trig -gers the corresponding rule and assigns to the attribute “Pharmacist Advice” of the class “Message” the value ‘Valid prescrip-tion’ which is then displayed to the user. The system also displays the knowledge triggering this alert: drug presentation name, drug dosage, laboratory results. If the prescription is not valid, the system as-signs to the attribute “Pharmacist Advice” of the class “Messag”' the value “Invalid Prescription”. The system displays the alert to the user with the detail of the prescrip-tion triggering this alert (drug presentaprescrip-tion name, drug dosage, etc.) and the corre -sponding drug dosage recommendation. For example, for an alert corresponding to the BR1 template, the recommendation displayed is: “For an eGFR < 15 ml/min/ 1.73 m2; adjusted dosage/ordinary dosage
ratio of 50%”.
The system instantiates the DCOM ob-jects required to query the drug knowledge base and then assigns input parameter valu-es to thvalu-ese objects to trigger the drug know-ledge base control rules. For example, to ob-tain the contraindications for a drug that has already been checked by our decision rules, we instantiate two main DCOM objects:
● ‘Products’ with the drug presentation
name as an input parameter to make it possible to search for the presence of the drug in the drug knowledge database
● ‘Monography’: generating the list of
contraindications for the prescription of this drug
The drug knowledge base recommenda -tions are associated with the recommen-dations displayed by our decision rules (see also 씰Appendix – Figure A-2).
3.7.2 Pilot Experiment
The alert system is currently deployed as a POJO (plain old Java object) client/server application. The HEGP EMR included (as of March 2010) 1,002,940 drug prescrip-tions written since its opening in 2000. The Rule Engine currently includes 140 rules covering 189 drug presentation names listed in the HEGP drug booklet. These rules currently correspond exclusively to the BR1 template: “Adaptation of drug dose
as a function of the patient’s glomerular filtration rate (GFR)”. The Rule Engine identified 71,413 prescriptions (100%) corresponding to the BR1 template. It triggered an alert for 5824 prescriptions (8.16%) and its runtime was 36 seconds.
4. Discussion and
Conclusion
CPOE/CDSS associations are increasingly being shown to be effective, but their use in hospitals remains limited [48]. A similar observation was reported in the “Roadmap for National Action on Clinical Decision Support” [49], which aimed to propose a series of actions to increase the capability of CPOE/CDSS and to increase their use throughout the health sector in the United States. Several studies have shown that physicians frequently override clinical de -cision support alerts [50–52]. Hsieh et al. [53] reported a frequency of overridden alerts of 80% of the 300 cases studied, with a clinical justification in each case. The au-thors concluded that there was evidence for ‘over alerting’ by the system. If…then rule-based alert systems are attractive because of the apparent simplicity of their implemen-tation. However, the implementation of such systems requires a significant infra-structure for the creation, maintenance/ updating and deployment of rules [54]. The decision rules giving rise to alerts are continually changing [55]. A process able to handle these changes is therefore neces -sary [56]. The Standish Group conducted a research study of 365 respondents relating to 8380 projects representing companies across major industrial sectors [57]. This study revealed that the three major factors underlying the success of software prod-ucts were: user involvement, executive management support and a clear statement of requirements. Martin Fowler, in the Agile Manifesto [58], supported the view that facilitating change is more effective than attempting to prevent change. The ability to respond to change often deter-mines the success or failure of a software project [59]. Moxey et al. [60], in a very re-cent study, argued that the integration of a CDSS into the workflow has a major im-pact on CDSS use.
We argue in this paper that adopting an ‘agile’ and business-oriented design meth-odology for the implementation and main-tenance of business rule-based decision support systems might both: 1) make it easier to achieve the objectives of the US Roadmap for National Action on Decision Support [49], 2) decrease the tendency to-wards ‘over alerting’, thereby increasing the efficacy of clinical decision making by fa-cilitating the maintenance of alerts through the inclusion of the end user (prescribers and/or pharmacists) early in the design process.
The principal finding of this study con-cerns the adaptation of the UP design life cycle. In five of the eight business rule de-sign framework (BRDF) dede-sign activities (씰Table 1), the participation of end users makes it possible to deal with the barriers between the different actors in the design process and possibly foster the future adop-tion and use of the CDSS. In the business modeling activity, we describe pharma -ceutical validation processes using the business use cases concept. Business use cases are essentially based on a structured textual description of business processes, making it possible to include pharmacists in this design activity. For the determi -nation of system requirements, pharma-cists participated in the description of sys-tem use cases and in business rules specifi-cation, through the relationship estab-lished between the structured textual de-scription of system use cases and the busi-ness rule templates. The use of decision tables to represent these templates also helped pharmacists to visualize the transi-tion from the textual descriptransi-tion of the templates to the first draft of business rules and to participate to the various iterations required to stabilize these draft rules. In the design and test activities, pharmacists con-tributed to business rules instantiation and
maintenance through the simple use of SBVR.
End-user participation was not practical for three of the eight BRDF design activities described in 씰Table 1. The system require-ments activity and the design activity in-volve many highly abstract concepts (UML classes, classes for analysis, etc.) and the method for extracting these concepts from the textual descriptions of use case systems is difficult for end users to understand. The actors involved in implementation must master one or more programming lan-guages (Java, SQL, etc.), which is generally not the case for end users of a system. However, according to the “Roadmap for Na -tional Action on Clinical Decision Sup-port” [49], CDSS interventions must be in-terpretable by both humans and machines. It is therefore necessary to represent system interventions in a standardized format [49]. One of the reasons for including busi-ness rules instantiation activity is to intro-duce an easily interpretable formalism for decision rules expression into the BRDF design life cycle. The use of standardized decision rule formalism makes it possible to share the clinical knowledge conveyed by the decision rules produced during the design process. The formalism used must therefore be a UML class-based, object-oriented (OO), extensible, non-property-dependent, platform-innon-property-dependent, inter-nationally accepted standard. Both GELLO [29] and SBVR were considered suitable as the formalism for decision rules expression in the BRDF framework. However, SBVR was found more user-friendly than GELLO, which is based on the object constraint lan-guage (OCL), initially developed for use by software designers. This makes it possible to write business rules using the business vocabulary of the end user, thereby increas-ing the participation of end users in the de-sign process. SBVR facilitates the definition
of a business-oriented ontology including concepts and relationships, definitions, synonyms, closed versus open world asser-tions and other features [61]. In addition, the SBVR metamodel defines mapping rules for XML and allows the use of an XML-based file interchange format for modeling business vocabularies and rules [46].
The BRDF was not designed for the automatic extraction of decision rules from a textual corpus, although it can be used for this purpose, as shown by our work with the data from Lindblad’s article [36]. The BRDF should be used for the extraction and design of decision rules in business contexts in which decision rules are not textually explicit.
This study has several limitations, the first of which concerns decision rule cat-egories. 씰Table 2 shows that the business rules implemented in this study cover only 24.4% of the total number of the
prescrip-tions validated by pharmacists. Thus, other types of rules, including other types of the advanced medication-related clinical deci-sion support [16], must be implemented in a production setting.
The second limitation concerns the do-main of application. The proposed frame-work was applied only to pharmaceutical validation activities. We therefore need to compare the application of this framework in this context with that in other applica -tion contexts such as drug prescrip-tion at the physician level.
The third limitation relates to the ex-pression of time in the business rules specification. SBVR provides no specific se -mantic formulations for the expression of time [46]. However, its authors [46] argue that an encompassing formulation can re-late a state or event indicated by objectifi-cation to points in time, periods and du-rations. More evaluation and comparison between SBVR and other languages
allow-ing the handlallow-ing of expressions relatallow-ing to time, such as Asbru and EON [28], are required.
Another limitation concerns the imple-mentation activity. We chose to implement and test decision rules in a business rule management system from IBM/ILOG – JRules® – because this makes it possible to involve end users in rule maintenance through its collaborative interface, Rule Team Server®, and makes the writing of business rules as easy as for SBVR. It is also interesting to consider the role of the busi-ness object model concept in the institution interoperability of clinical de -cision support systems [62]. However, this activity remains platform-dependent and the choice of rule engine managing the execution of alert system decision rules de-pends on information system constraints and the methodological and economic choices of designers and policy makers. It will therefore be important to test the
plementation of SBVR rules using other business rule management systems.
Future on the BRDF adopted should focus on its effective implementation and use. More precise tests could be carried out, and the impact of the system and the effi-ciency of the decision rules designed could be evaluated by integrating the rules into the production HEGP CIS. This would make it possible to take into account new requirements and adjustments not con-sidered during the initial design inter-actions and to assess the true agility of the BRDF and the rapidity with which end-user requirements can be managed. We proposed in this paper a decision rule man-agement method as a process solution for the ‘agile’ handling of knowledge-based business rule changes. However, our ex-perience suggests that a process solution is necessary but not sufficient. Technical so -lutions that have already proved effective should be associated with the process so -lution to increase ‘agility’ in the handling of business rule changes.
Future efforts to improve the architec-ture of the alert system should focus on the integration of other technical solutions. The drug knowledge base currently inte-grated within the architecture of the system can be used to test other types of decision rules. The use of a more comprehensive business-oriented ontology should facili-tate the maintenance of the business rules [63]. Experience has shown that software development tends to be more successful if it proceeds by the development of proto-types [64]. It is also difficult to query the local information model of the operational databases underlying the CPOE and EMR components, for the testing and validation of prototype decision rules before their implementation. The large number of rela -tional tables (more than 800 in the local CPOE/EMR) required to facilitate patient management makes it more difficult to carry out the statistical queries required for the testing and validation of rules. Thanks to the optimization of the information model, it should be possible to connect our alert system to the HEGP clinical data warehouse (CDW) [65] for use as a busi-ness rule-experimental laboratory tool. This will make it possible to test business rules and to obtain results more rapidly
be-fore their exploitation. Finally, a more de-tailed evaluation of the degree of ‘agility’ of the proposed decision rules management framework should be performed [66]. Traditional plan-based methods clearly cannot provide the necessary design tools and stages for the design and maintenance of decision rules (씰Table 1), but we feel that it is nonetheless essential to compare the decision rules produced by the two methods, to confirm the superiority of the ‘agile’ approach [66].
Acknowledgments
We thank ILOG for providing us with an evaluation version of ILOG JRules and RESIP for providing us with BCB. Dr Philippe Guillaume from the pharmacy of Georges Pompidou Hospital and Dr Ca-therine Duclos from the Lim&Bio Labora-tory were responsible for writing the requirements for the rule system. We would also particularly like to thank Mrs. Virginie Korb for her helpful reviews.
References
1. Moore N, Lecointre D, Noblet C, Mabille M. Fre-quency and cost of serious adverse drug reactions in a department of general medicine. Br J Clin Phar-macol 1998; 45 (3): 301–308.
2. Oliven A, Michalake I, Zalman D, Dorman E, Yeshu-run D, Odeh M. Prevention of prescription errors by computerized, on-line surveillance of drug order entry. Int J Med Inform 2005; 74 (5): 377–386. 3. Van der Sijs H, Aarts J, Vulto A, Berg M. Overriding
of drug safety alerts in computerized physician order entry. J Am Med Inform Assoc 2006; 13 (2): 138–147.
4. Garg AX, Adhikari NK, McDonald H, Arellano MP, Devereaux PJ, Beyene J, Sam J, Haynes RB. Effects of computerized clinical decision sup-port systems on practitioner performance and pa-tient outcomes: a systematic review. JAMA 2005; 293 (10): 1223–1238.
5. Bhole M, Sansgiry SS. Computerized physician order entry systems: is the pharmacist’s role justi-fied? J Am Med Inform Assoc 2004; 11 (2): 125–126. 6. Fair MA, Pane F. Pharmacist interventions in elec-tronic drug orders entered by prescribers. Am J Health Syst Pharm 2004; 61 (12): 1286–1288. 7. Dooley MJ, Allen KM, Doecke CJ, Galbraith KJ,
Taylor GR, Bright J, Carey DL. A prospective multi-centre study of pharmacist initiated changes to drug therapy and patient management in acute care gov-ernment funded hospitals. Br J Clin Pharmacol 2004; 57 (4): 513–521.
8. Leape LL, Cullen DJ, Clapp MD, Burdick E, De -monaco HJ, Erickson JI, Bates DW. Pharmacist par-ticipation on physician rounds and adverse drug
events in the intensive care unit. JAMA 1999; 282 (3): 267–270
9. Order of August 9, 1991, implementing Article R. 5203 Code of Public Health)
10. Order of March 31, 1999 related to “prescription, to drug dispensation and administration subject to the regulation of poisonous substances in health in-stitutions, To Hospitals labour unions and to socio-medical establishments with a pharmacy for inter-nal use referred to in Article L. 595-1 of the Public Health Code, 1999.
11. Estellat C, Colombet I, Vautier S, Huault-Quentel J, Durieux P, Sabatier B. Impact of pharmacy vali-dation in a computerized physician order entry context. Int J Qual Health Care 2007.
12. McMullin ST, Reichley RM, Kahn MG, Dunagan WC, Bailey TC. Automated system for identifying potential dosage problems at a large university hos-pital. Am J Health Syst Pharm 1997; 54 (5): 545–549.
13. Mullett CJ, Evans RS, Christenson JC, Dean JM. De-velopment and impact of a computerized pediatric antiinfective decision support program. Pediatrics 2001; 108 (4): E75.
14. Shekelle PG, Morton SC, Keeler EB. Costs and Benefits of Health Information Technology. Evi-dence Report/Technology Assessment No. 132. (Prepared by the Southern California Evidence-based Practice Center under Contract No. 290-02-0003.) AHRQ Publication No. 06-E006. Rockville, MD: Agency for Healthcare Research and Quality; April 2006.
15. Seger DL. Computerized POE: changing roles for the clinical pharmacist. J Am Pharm Assoc (Wash) 1999; 39 (5): 710.
16. Kuperman GJ, Bobb A, Payne TH, Avery AJ, Gandhi TK, Burns G, Classen DC, Bates DW. Medication-related clinical decision support in computerized provider order entry systems: a review. J Am Med Inform Assoc 2007; 14 (1): 29–40.
17. Greenes RA. Clinical Decision Support: The Road Ahead. 1st ed. Academic Press Inc; 2006. 18. Aarts J, Doorewaard H, Berg M. Understanding
im-plementation: the case of a computerized physician order entry system in a large Dutch university medical center. J Am Med Inform Assoc 2004; 11 (3): 207–216.
19. Peleg M, Tu S. Decision support, knowledge repre-sentation and management in medicine. Methods Inf Med 2006; 45 (Suppl 1): 72–80.
20. Boehm B. Get ready for agile methods, with care. Computer 2002; 35 (1): 64–69.
21. Knape T, Hederman L, Wade VP, Gargan M, Harris C, Rahman Y. A UML Approach to process model-ling of clinical practice guidelines for enactment. Stud Health Technol Inform 2003; 95: 635–640. 22. LeBozec C, Jaulent MC, Zapletal E, Degoulet P.
Uni-fied modeling language and design of a case-based retrieval system in medical imaging. Proc AMIA Symp 1998. pp 887–891.
23. Hahn GJ, Doganaksoy N, Hoerl R. THE – EVOL-UTION – OF – SIX – SIGMA – PB – Taylor & Fran-cis. Quality Engineering 2000; (3): 317. 24. Davenport T. Why Six Sigma Is on the Downslope –
Harvard Business Review (Internet). Last accessed Jan 3, 2010. Available from: http://blogs.hbr.org/ davenport/2008/01/why_six_sigma_is_on_the_ downsl.html
25. Osheroff JA. Clinical Decision Support Imple -menter’s Workbook (Internet). Last accessed Jan 3, 2010. Available from: http://www.himss.org/ content/cdsw/front.pdf
26. Jacobson I, Booch G, Rumbaugh J (eds). The Uni-fied Software Development Process. Addison-Wes-ley Professional; 1999
27. Vliet HV. Software Engineering: Principles and Practice. 2nd ed. Wiley; 2007
28. Peleg M, Tu S, Bury J, et al. Comparing computer-in-terpretable guideline models: a case-study approach. J Am Med Inform Assoc 2003; 10 (1): 52–68. 29. Sordo M, Boxwala AA, Ogunyemi O, Greenes RA.
Description and status update on GELLO: a pro-posed standardized object-oriented expression lan-guage for clinical decision support. Medinfo 2004; 11 (Pt 1): 164–168.
30. Shahar Y, Miksch S, Johnson P. The Asgaard project: a task-specific framework for the application and critiquing of time-oriented guidelines. Artif Intell Med 1998; 14(1, 2): 29–52.
31. Musen M, Tu S, Das A, Shahar Y. EON: A component-based approach to automation of protocol-directed therapy. J Am Med Inform Assoc 1996; 3: 367–388. 32. Ohno-Machado L, Gennari JH, Murphy SN, Jain
NL, Tu SW, Oliver DE, Pattison-Gordon E, Greenes RA, Shortliffe EH, Barnett GO. The guideline inter-change format: a model for representing guidelines. J Am Med Inform Assoc 1998; 5: 357–372. 33. Fox J, Johns N, Rahmanzadeh A. Disseminating
medical knowledge: the PROforma approach. Artif Intell Med 1998; 14 (1, 2): 157–182.
34. Capurro D, Kalet IJ. Representation of a simple and unambiguous clinical guideline in a computer in-terpretable language. AMIA 2009 Symposium Pro-ceedings.
35. “Anonymous” Semantics of Business Vocabulary and Business Rules Specification. Document de specifica-tion de l’OMG, 2006. http://www.omg.org/docs/for mal/08-01.02.pdf. Last accessed 2008/05/02. 36. Lindblad CI, Hanlon JT, Gross CR, Sloane RJ,
Pieper CF, Hajjar ER, Ruby CM, Schmader KE. Clinically important drug-disease interactions and their prevalence in older adults. Clin Ther 2006; 28 (8): 1133–1143.
37. Degoulet P, Marin L, Lavril M, Le Bozec C, Delbecke E, Meaux JJ, Rose L. The HEGP component based clinical information system. Int J Med Inform 2003; 69 (2–3): 115–126.
38. THERIAQUE data bank web portal (Internet). Last accessed May 15, 2010. Available from: http://www. theriaque.org/
39. Séné B, Venot A, de Zegher I, Milstein C, Errore S, de Rosis F, Strauch G. A general model of drug pre-scription. Methods Inf Med 1995; 34 (4): 310–317. 40. Gamma E, Johnson R, Helm R. Vissides J. Design patterns: Elements of reusable object-oriented soft-ware. Addison-Wesley Professional; 1995.
41. IBM developerWorks: WebSphere ILOG Business Rule Management Systems (Internet). Nov 16, 2009. Last accessed 2010 Jan 3, 2010. Available from: http://www.ibm.com/developerworks/websphere/ zones/brms/
42. Ambler S. How to record the transactional logic behind UML object models. http://www.ddj.com/ dept/architect/184414624?cid=Ambysoft. Last ac-cessed 2008/05/15.
43. Nijpels R. Business Rules in Requirements Analysis. Business Rules Journal 2005; 6 (12). http://www. BRCommunity.com/a2005/b259.html. Access with login, last accessed 2008/05/15.
44. HL7 Reference Information Model. http://www. hl7.org/Library/data-model/RIM/modelpage_ mem.htm.
45. Information Model Based on HL7 RIM for the Radiology Department in Japan. Japanese Associ-ation of Healthcare InformAssoci-ation Systems Industry. Technical Report 2001-15. http://www.jahis.jp/en/ MODELING/modeling/right.htm
46. “Anonymous” Business Semantics of Business Rules, Business Rules Team Response to RFP: SBVR Submission bei/2005-08-01 Version 8. http:// www.omg.org/docs/bei/05-08-01.pdf last accessed on 2008/05/02.
47. Kuperman GJ, Reichley RM, Bailey TC. Using com-mercial knowledge bases for clinical decision sup-port: opportunities, hurdles, and recommen-dations. J Am Med Inform Assoc 2006; 13 (4): 369–371.
48. Ash JS, Gorman PN, Seshadri V, Hersh WR. Com-puterized physician order entry in U.S. hospitals: results of a 2002 survey. J Am Med Inform Assoc 2004; 11 (2): 95–99. Epub Nov 21, 2003. 49. Osheroff JA, Teich JM, Middleton B, Steen EB,
Wright A, Detmer DE. A roadmap for national ac-tion on clinical decision support. J Am Med Inform Assoc 2007; 14 (2): 141–145. Epub Jan 9, 2007. 50. Abookire SA, Teich JM, Sandige H, Paterno MD,
Martin MT, Kuperman GJ, Bates DW. Improving allergy alerting in a computerized physician order entry system. Proc AMIA Symp 2000. pp 2–6. 51. Weingart SN, Toth M, Sands DZ, Aronson MD,
Davis RB, Phillips RS. Physicians’ decisions to over-ride computerized drug alerts in primary care. Arch Intern Med 2003; 163 (21): 2625–2631.
52. Van der Sijs H, Aarts J, Vulto A, Berg M. Overriding of drug safety alerts in computerized physician order entry. J Am Med Inform Assoc 2006; 13 (2): 138–147.
53. Hsieh TC, Kuperman GJ, Jaggi T, Hojnowski-Diaz P, Fiskio J, Williams DH, Bates DW, Gandhi TK. Characteristics and consequences of drug allergy alert overrides in a computerized physician order entry system. J Am Med Inform Assoc 2004; 11 (6): 482–491. Epub Aug 6, 2004.
54. Greenes RA. Why Clinical Decision Support is Hard to Do. AMIA Annu Symp Proc 2006. pp 1169–1170. 55. Oppenheim MI, Mintz RJ, Boyer AG, Frayer WW.
Design of a clinical alert system to facilitate devel-opment, testing, maintenance, and user-specific notification. Proc AMIA Symp 2000. pp 630–634. 56. Kuperman GJ, Fiskio JM, Karson A. A process to
maintain the quality of a computerized knowledge base. Proc AMIA Symp 1999. pp 87–91. 57. The Standish Group. The Chaos Report (Internet).
1995. Last accessed Dec 3, 2009. Available from: http://www.projectsmart.co.uk/docs/chaos-report. pdf
58. Fowler M. The Agile Manifesto (Internet]). 2001. Last accessed Jan 3, 2010. Available from: http:// andrey.hristov.com/fht-stuttgart/The_Agile _Manifesto_SDMagazine.pdf
59. Williams L, Cockburn A. Agile software develop -ment: it’s about feedback and change. Computer 2003; 36 (6): 43, 39.
60. Moxey A, et al. Computerized clinical decision sup-port for prescribing: provision does not guarantee uptake – 17 (1): 25 – Journal of the American Medi-cal Informatics Association (Internet). Llast ac-cessed Jan 13, 2010. Available from: http://jamia. bmj.com/content/17/1/25.abstract
61. Linehan MH. SBVR Use Cases (Internet). In: Pro-ceedings of the International Symposium on Rule Representation, Interchange and Reasoning on the Web. Orlando, Florida: Springer-Verlag; 2008. pp 182–196. Last accessed Jan 3, 2010. Available from: http://portal.acm.org/citation.cfm?id=1483286 62. Goldberg HS, Vashevko M, Pastilnik A, Smith K,
Plaks N, Blumenfeld BM. Evaluation of a commer-cial rule engine as a basis for a clinical decision sup-port service. AMIA Annu Symp Proc 2006. pp 294–298.
63. Kashyap V, Morales A, Hongsermeier T. On imple-menting clinical decision support: achieving scal-ability and maintainscal-ability by combining business rules and ontologies. AMIA Annu Symp Proc 2006. pp 414–418.
64. Wright A, Sittig DF. SANDS: a service-oriented architecture for clinical decision support in a National Health Information Network. J Biomed Inform 2008; 41 (6): 962–981.
65. Zapletal E, Rodon N, Grabar N, Degoulet P. Meth-odology of integration of a clinical data warehouse with a clinical information system: the HEGP case. Stud Health Technol Inform 2010; 160 (Pt 1): 193–197.
66. Qumer A, Henderson-Sellers B. An evaluation of the degree of agility in six agile methods and its applicability for method engineering. Inf Softw Techno 2008; 50 (4): 280–295.
Appendix
Fig. A-2 example of the file generated by the Rule Engine and the drug knowledge base for analysis of the HEGP EMR Translation: “Prescription line number 1
System advice: invalid prescription
Data justifying this decision: drug presentation name ZYLORIC 100MG CPR, prescription unit: tablet, time unit duration: TLJ, dosage: 2.0, GFR: 15.0, busi-ness rule ID triggered this alert: ZYLORIC – 100 – CPR
Recommendation: for a GFR between 15 and 30 ml/min/1.73 m2, the dosage for this drug should be 150 mg/day ***Knowledge base checking (BCB) ***
This drug is contraindicated in the following cases:
● Allergy to allopurinol or one of the excipients ● In children under the age of 6 years ● During breast-feeding
…
Prescription line number 2 …”
![Table 3 Part of a decision table representing an “if then else” rule corresponding to the drug-disease interactions of Lindblad’s study [36]](https://thumb-us.123doks.com/thumbv2/123dok_us/9800977.2865263/7.892.323.826.724.1021/table-decision-table-representing-corresponding-disease-interactions-lindblad.webp)
