A Business Rules Design Framework for a Pharmaceutical Validation

May 12, 2012 - 3Georges Pompidou University Hospital (HEGP), Paris, France. Keywords ..... ness rule management system (IBM/ILOG. JRules®). 2. Materials ...
1MB taille 3 téléchargements 625 vues
36

© Schattauer 2011

Original Articles

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 administration, drug therapy, computer-assisted organization and administration

Summary Objectives: Several alert systems have been developed to improve the patient safety aspects 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 implementation. We propose here an ‘agile’ business 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 activities, subactivities, actors and UML artifacts that could be used to enhance the agility of the proposed framework. We then applied the

Correspondence to: Abdelali Boussadi Laboratoire de recherche en ingénierie des connaissances et e-santé (INSERM UMR_S 872, Eq 20) 15 rue de l’école de médecine 75006 Paris France E-mail: [email protected]

1. Introduction Many studies dealing with drug prescription errors have provided support for the use of clinical decision support systems (CDSS) within computerized physician order entry (CPOE) systems [1–4]. However, studies evaluating CPOE and CDSS have

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 business 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 context of drug dosage adaption to the patients’ clinical and biological contexts. Pilot experiment shows that business rules modeled with BRDF and implemented as an alert system triggered an alert for 5824 of the 71,413 prescriptions considered (8.16%). Conclusion: A business rule design framework approach meets one of the strategic objectives for decision support design by taking into account three important criteria posing a particular challenge to system designers: 1) business processes, 2) knowledge modeling of the context of application, and 3) the agility of the various design steps.

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

frequently reported a reluctance of physicians 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) efficiently [6], thereby decreasing the costs associated with these errors [7]. Leape et al.

[8] estimated the impact on the frequency of ADE of the changes introduced by pharmacists. 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 pharmacists 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 prescription delivery loop. In a computerized environment, pharmaceutical validation involves an analysis of the physicians’ drug prescriptions entered with a CPOE to detect the possible errors (씰Fig. 1). Pharmacists 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 support system (CDSS). If the prescription is deemed dangerous for the patient, the pharmacist adds a warning into the EMR/ CPOE, and eventually communicates/telephones with the prescriber to discuss proposed changes in the prescription. Two barriers 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 provide 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 validation activities of pharmacists more efficient; reduce communications with physicians, and thereby potentially increasing prescription safety at a reasonable cost and with an acceptable workload for pharma-

Methods Inf Med 1/2011

Downloaded from www.methods-online.com on 2012-05-12 | IP: 82.247.116.130 For personal or educational use only. No other uses without permission. All rights reserved.

A. Boussadi et al.: A Business Rules Design Framework for a Pharmaceutical Validation and Alert System

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 pharmacists’ recommendations. Mullet et al. [13] modified an existing computerized decision 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 number of pharmacist interventions required due to the administration of erroneous drug doses. In their study, as in most published studies on alert systems, Mullet et al. [13] focused on evaluation of the system but provided little information about the methodology leading to system implementation. One of the general conclusions of a report published by the Agency for Healthcare Research and Quality (AHRQ) of the US Department of Health & Human Services was that the generalization of knowledge concerning the types of health information technologies (HIT) available and their methods of implementation would be very useful for health organizations, overcoming current limitations to the widespread implementation of HIT [14]. Pharmaco-informatics specialists have suggested that clinical pharmacists should play a key role in the management of medication-associated knowledge, and in the design and implementation of CPOE systems [15]. Kuperman et al. [16] reviewed the common categories of medicationrelated CDS within CPOE and defined several questions for facilitating the classification 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) currently prevent maximal benefit? ● What steps might facilitate further development of the specific category of decision support?

Fig. 1 Drug delivery loop in French hospitals and associated computing tools

He then defines two main categories of decision rules associated with the execution of a CDSS: basic and advanced decision rules. Basic CDS are more straightforward 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 strategies 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 implementation processes have both a social and a technical dimension [18, 19]. System designers and developers must therefore understand the organizational dynamics (business process modeling) and relate them to the technical aspects (design process management). The implemented system must respond to the user’s requirements, 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’ software development methods. ‘Agile’ development 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 design 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 approaches developed in software engineering, such as business process engineering, should be used in the future, allowing companies 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

© Schattauer 2011

Methods Inf Med 1/2011

Downloaded from www.methods-online.com on 2012-05-12 | IP: 82.247.116.130 For personal or educational use only. No other uses without permission. All rights reserved.

37

38

A. Boussadi et al.: A Business Rules Design Framework for a Pharmaceutical Validation and Alert System

implementer’s manual. This manual provides a useful framework for CDSS development, with a worksheet for each development step, to determine specific CDSS goals and objectives, to list the information 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 language, and this step is not clearly explained in the manual. The authors of the UML recommend the use of approaches developed in software engineering, such as the unified process (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 manages 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 context of application and the phase of the project. UP defines business process modeling 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 implementing these languages can be used to produce decision rules from clinical guidelines such as the Arden syntax, GELLO [29], Asbru [30], EON [31], GLIF [32], or Proforma [33]. However, due to the complexity and ambiguity of most clinical practice guidelines [17, 34], it remains a daunting enterprise to convert them to their formal representation [17]. The complexity involved in the use of these approaches goes against the ‘agile’ nature of the desired business rules modeling framework. Ideally, the selected formalism should be articulated with the design process 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 response 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 development of semantic templates, business vocabularies and business rules. It is an object 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 International Standards Organization (ISO) standard for the English language; SBVR business rules are therefore expressed in a form very close to natural language and appropriate 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 validation of drug prescriptions and the generation of alerts. This adaptation of UP takes into account three important criteria posing a particular challenge to system designers [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 software 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 activity at Georges Pompidou European Hospital (HEGP), and 2) data from Lindblad’s study [36], to design and maintain business rules for pharmaceutical validation support. Finally, we have implemented and evaluated the performance of the resulting business rules within a commercial business rule management system (IBM/ILOG JRules®).

2. Materials and Methods 2.1 Adaptation of the UP and Application of the Proposed Framework We analyzed the design life cycle of the UP, with the objective of adapting it to propose an agile framework dedicated to the specification of decision rules. We aimed to: ● determine, for each phase, the activities, subactivities, actors and UML artifacts required to achieve the desired objective; ● add new activities to the UP design life cycle if required, and ● delete any UP activities deemed unnecessary. 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 pharmaceutical 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 admission-discharge and transfer, an electronic medical record, and a CPOE components 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 concepts dictionary that facilitates their reuse by other components of the CIS. The dictionary includes ICD10 and SNOMED 3.5, DRG codes for diagnosis and clinical observations 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]. Information on drug-drug interactions is imported from the Vidal® pharmaceutical databank. Terminology for biological concept (7291 as of June 2010) in the concept dictionary is local to the HEGP CIS but in the process of migration towards LOINC. HEGP CIS is currently used for every prescription of biological or radiological tests,

Methods Inf Med 1/2011

© Schattauer 2011

Downloaded from www.methods-online.com on 2012-05-12 | IP: 82.247.116.130 For personal or educational use only. No other uses without permission. All rights reserved.

A. Boussadi et al.: A Business Rules Design Framework for a Pharmaceutical Validation and Alert System

but for the drug prescriptions for only 331 beds. The workflow organization of the drug prescription analysis activity at HEGP enables pharmacists to validate the computerized prescriptions, but already requires four full-time pharmacists. Physicians enter drug prescriptions directly into Dx-C@re® for validation by pharmacists via the pharmacy interface of the Dx-C@re® CPOE: Valid_Pharma®. Physicians and pharmacists make use of the same electronic medical record (EMR) management tools. HEGP aims is to achieve CIS use for the drug prescriptions for 650 beds in 2011 making necessary the development of a more efficient 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 conducted a series of interviews with the pharmacists responsible for pharmaceutical validation, to assess their needs. This business requirements analysis confirmed that several categories of alerts were required: drug dosage adjustment, drug-allergy checking, checking of drug-disease interactions and contraindications. Basic decision rules [16], such as checks for duplicate treatment, automatic dose control for oral forms and searches for drug-drug interactions, are already available in Dx-C@re®. However, advanced decision rules [16] are not currently implemented in this component of the CIS. We therefore decided to develop decision rules corresponding to advanced guidelines for medicationassociated laboratory testing [16]. This choice was then validated by considering its impact on the workload for the pharmacists involved in the analysis of prescriptions for the 331 beds for which computerized drug prescription is currently in operation. Three business rules (BRx) templates were selected for the evaluation: ● BR1: Adaptation of drug dose as a function of the patient’s glomerular filtration rate (GFR) ● BR2: Adaptation of drug dose as a function of international 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 corresponding to the advanced checking of drugdisease interactions and contraindications [16]. The authors propose a list of 28 drugdisease interactions in the elderly for which a consensus was reached. The list is presented with diseases on one side and drug conditions on the other: for example, peptic 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 purpose. Séné’s drug prescription model is based on an object-oriented formalism different from the UML: Coad-Yourdon formalism. It was therefore necessary to define rules for mapping Coad-Yourdon graphic elements onto UML graphic elements, to rewrite Séné’s model in UML. We also modified 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 experiment were implemented with IBM/ILOG JRules®. This process begins with the implementation of the execution object model (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 implemented execution object model via a verbalization process. This process attaches natural-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 combinations of modifiable building blocks. If the business object model contains an attribute “Presentation Name” for the class “Drug”, the corresponding textual business rule will contain two phrases {the Presentation Name} of {a Drug}. Decision trees provide an alternative and more convenient way of viewing and managing large sets of business 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 condition 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 diamond-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 business rules. They consist of rows and columns in which each row corresponds to a single rule with, for example, the attribute “Presentation Name” and the class name “Drug” as column names defining the conditions and actions applying to the rules [41]. The order in which the various implemented 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 depends on the guard condition of each transition 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

© Schattauer 2011

Methods Inf Med 1/2011

Downloaded from www.methods-online.com on 2012-05-12 | IP: 82.247.116.130 For personal or educational use only. No other uses without permission. All rights reserved.

39

40

A. Boussadi et al.: A Business Rules Design Framework for a Pharmaceutical Validation and Alert System

Table 1 Comparison of UP design activities and the activities of the proposed framework BRDF activities

Activities described Artifacts in the UP approach

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

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 modeling for the validation of drug prescriptions. 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 prescriptions” comprised one main scenario and 14 alternative scenarios (씰Fig. 2).

3.2 System Requirements Activity (Activity Number 2, System Use Case Diagrams)a

Fig. 2 Part of sequence diagram corresponding to an alternative scenario of the business use case “To validate prescriptions”

alert is triggered in abnormal conditions, such as an inappropriate potassium level or a low glomerular filtration rate.

3. Results The activities required to meet our objectives 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 modeling of business processes [26]. Business use case diagrams can be used to model the business processes involved in drug prescription validation activity (씰Table 1).

a

See Table 1 for more details

Requirements are described with system use case diagrams. Business use case models facilitate the development of system use case models [26]. Eight system use cases were identified for improving the pharmaceutical validation interface. Three system use cases related to the business use case “To validate prescriptions” were identified 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

Methods Inf Med 1/2011

© Schattauer 2011

Downloaded from www.methods-online.com on 2012-05-12 | IP: 82.247.116.130 For personal or educational use only. No other uses without permission. All rights reserved.

A. Boussadi et al.: A Business Rules Design Framework for a Pharmaceutical Validation and Alert System

supplementing the determination of requirements [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 prescriptions 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 prescriptions) of all prescriptions in the departments for which pharmaceutical validation 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 description 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 establish a list of molecules, biological markers and clinical situations for which these rules should trigger alerts. We described each business rule template textually in terms of the following items: identification (ID), name, description, example, source, linked rule, according to Ambler’s recommendations [42]. The system use cases attached to each business rule’s BRx template were as follows: ● System use case: “Validate the prescriptions of patients with renal failure treated with drugs for which dose should be adapted as a function of glomerular filtration rate”, consisting of one main scenario and eight alternative scenarios. ● 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 function of the patient’s potassium levels”,

Table 2 Business rules templates identified in the new activity ‘Specification of business rules’ from 1 January 2006 to 1 January 2007

Business rules templates (BRx)

Drug prescription

Adaptation of drug dose as a function of the patient’s glomerular filtration rate (GFR)

12,032 (8.04%)

Adaptation of drug dose as a function of international 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 hyperkalemia 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%)

consisting of one main scenario and nine alternative scenarios. Each system use case is described by standardized structured tables containing the following items: use case designation, scope, main actor, business workers (secondary actors), triggering event, pre-conditions, post-conditions, 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 determination 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 generated a new system use case, the abstract use case ‘To validate prescription’ (씰Fig. 3). For the second feasibility study, we considered the list of 28 drug-disease interactions as business rule templates. Following the same method, we listed the molecules from the HEGP drug booklet corresponding 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 Requirements 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, constituting the first draft of the business object model. The following analysis classes were identified for pharmaceutical validation activities at HEGP: ● one control class: “Pharmaceutical Validation 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 Validation Data”, “Laboratory Result”, “Drug”, “Prescription”, “Patient”, and “Message”. Execution of the main scenario of the abstract system use case: ‘To validate prescription’, 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 introduction of the new ‘Specification Business Rules’ activity into the UP design life cycle on the ‘System Requirements Analysis’ 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.

© Schattauer 2011

Methods Inf Med 1/2011

Downloaded from www.methods-online.com on 2012-05-12 | IP: 82.247.116.130 For personal or educational use only. No other uses without permission. All rights reserved.

41

42

A. Boussadi et al.: A Business Rules Design Framework for a Pharmaceutical Validation and Alert System

Fig. 3 Structuring of system use cases

Table 3 Part of a decision table representing an “if then else” rule corresponding to the drug-disease interactions of Lindblad’s study [36]

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 stereotypes 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 completion 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 vocabulary model. For example, pharmacists preferred the label ‘Drug’ for the class “Drug Preparation”. Certain relationships between

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 antidepressants

≥ 65

Opioid analgesics

≥ 65

classes were also modified, such as the relationship between the “Prescription Administration” and Event classes. We think it is preferable 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 relationship between the “Prescription Adminis-

Methods Inf Med 1/2011

© Schattauer 2011

Downloaded from www.methods-online.com on 2012-05-12 | IP: 82.247.116.130 For personal or educational use only. No other uses without permission. All rights reserved.

A. Boussadi et al.: A Business Rules Design Framework for a Pharmaceutical Validation and Alert System

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 equivalent 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

AcuteDiseaseAct / Observation

Act / Observation

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 downloading HL7 RIM 2.20 [44], we analyzed the various HL7 RIM classes and their attributes, to

sent the data for our model on the right (see 씰Appendix – 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 Lindblad’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 ‘Antecedent’, whereas the condition ‘age’ corresponds 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 ‘DementiaAnticholinergic drugs (excluding tricyclic antidepressants)’ was rejected by the expert pharmacists at HEGP.

3.6 Business Rule Instantiation Activity (Activity Number 6, identify those most similar in terms of their Class Diagram and Business definition, attributes and designation to our Rule Formalism)a 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-

Our adaptation of the construction phase was also associated with the introduction of a new activity: ‘Business Rules Instanti-

© Schattauer 2011

Methods Inf Med 1/2011

Downloaded from www.methods-online.com on 2012-05-12 | IP: 82.247.116.130 For personal or educational use only. No other uses without permission. All rights reserved.

43

44

A. Boussadi et al.: A Business Rules Design Framework for a Pharmaceutical Validation and Alert System

ation’. The instantiation of rules corresponding to the business object model requires the identification and naming of relevant relationships between classes. The rules mapping SBVR syntax onto the business object model [46] are then applied. For example, class name in the business object 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 pharmacists for each business rule template BRx, taking into account all related active ingredients. 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 include: ● 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 function of the business object model, using the mapping rules between SBVR syntactic elements and the graphic elements 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 corresponding business object model. The implementation 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 process, we adopted a system architecture with the following components (씰Fig. 6):









IBM/ILOG JRules®Rule Studio® (business rule development studio): a development environment allowing to write new rules or to manage changes to existing 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 application 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 decision rules [47]. The inclusion of such a knowledge base is also required to anticipate the extension of the alert system to categories 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 programmer and the alert system within the current architecture. The programmer implements the business rule templates corresponding 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®, instantiate 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 operation 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 triggers the corresponding rule and assigns to the attribute “Pharmacist Advice” of the class “Message” the value ‘Valid prescription’ 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 assigns 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 prescription triggering this alert (drug presentation name, drug dosage, etc.) and the corresponding 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 objects required to query the drug knowledge base and then assigns input parameter values to these objects to trigger the drug knowledge base control rules. For example, to obtain 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 recommendations are associated with the recommendations 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 prescriptions 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

Methods Inf Med 1/2011

© Schattauer 2011

Downloaded from www.methods-online.com on 2012-05-12 | IP: 82.247.116.130 For personal or educational use only. No other uses without permission. All rights reserved.

A. Boussadi et al.: A Business Rules Design Framework for a Pharmaceutical Validation and Alert System

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. Fig. 5 SBVR instance rule corresponding to the BRI template

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 decision 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 authors concluded that there was evidence for ‘over alerting’ by the system. If…then rulebased alert systems are attractive because of the apparent simplicity of their implementation. However, the implementation of such systems requires a significant infrastructure 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 necessary [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 products 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 determines the success or failure of a software project [59]. Moxey et al. [60], in a very recent study, argued that the integration of a CDSS into the workflow has a major impact on CDSS use.

We argue in this paper that adopting an ‘agile’ and business-oriented design methodology for the implementation and maintenance 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 towards ‘over alerting’, thereby increasing the efficacy of clinical decision making by facilitating 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 concerns the adaptation of the UP design life cycle. In five of the eight business rule design framework (BRDF) design 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 adoption and use of the CDSS. In the business modeling activity, we describe pharmaceutical 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 determination of system requirements, pharmacists participated in the description of system use cases and in business rules specification, through the relationship established between the structured textual description of system use cases and the business rule templates. The use of decision tables to represent these templates also helped pharmacists to visualize the transition from the textual description 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 contributed 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 requirements activity and the design activity involve 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 languages (Java, SQL, etc.), which is generally not the case for end users of a system. However, according to the “Roadmap for National Action on Clinical Decision Support” [49], CDSS interventions must be interpretable by both humans and machines. It is therefore necessary to represent system interventions in a standardized format [49]. One of the reasons for including business rules instantiation activity is to introduce 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, objectoriented (OO), extensible, non-propertydependent, platform-independent, internationally 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 language (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 increasing the participation of end users in the design process. SBVR facilitates the definition

© Schattauer 2011

Methods Inf Med 1/2011

Downloaded from www.methods-online.com on 2012-05-12 | IP: 82.247.116.130 For personal or educational use only. No other uses without permission. All rights reserved.

45

46

A. Boussadi et al.: A Business Rules Design Framework for a Pharmaceutical Validation and Alert System

Fig. 6 Execution scenario implementing all the current components of the alert system architecture

of a business-oriented ontology including concepts and relationships, definitions, synonyms, closed versus open world assertions 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 categories. 씰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 decision support [16], must be implemented in a production setting. The second limitation concerns the domain of application. The proposed framework was applied only to pharmaceutical validation activities. We therefore need to compare the application of this framework in this context with that in other application contexts such as drug prescription at the physician level. The third limitation relates to the expression of time in the business rules specification. SBVR provides no specific semantic formulations for the expression of time [46]. However, its authors [46] argue that an encompassing formulation can relate a state or event indicated by objectification to points in time, periods and durations. More evaluation and comparison between SBVR and other languages allow-

ing the handling of expressions relating to time, such as Asbru and EON [28], are required. Another limitation concerns the implementation 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 business object model concept in the multiinstitution interoperability of clinical decision support systems [62]. However, this activity remains platform-dependent and the choice of rule engine managing the execution of alert system decision rules depends on information system constraints and the methodological and economic choices of designers and policy makers. It will therefore be important to test the im-

Methods Inf Med 1/2011

© Schattauer 2011

Downloaded from www.methods-online.com on 2012-05-12 | IP: 82.247.116.130 For personal or educational use only. No other uses without permission. All rights reserved.

A. Boussadi et al.: A Business Rules Design Framework for a Pharmaceutical Validation and Alert System

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 efficiency 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 considered during the initial design interactions and to assess the true agility of the BRDF and the rapidity with which enduser requirements can be managed. We proposed in this paper a decision rule management method as a process solution for the ‘agile’ handling of knowledge-based business rule changes. However, our experience suggests that a process solution is necessary but not sufficient. Technical solutions that have already proved effective should be associated with the process solution to increase ‘agility’ in the handling of business rule changes. Future efforts to improve the architecture of the alert system should focus on the integration of other technical solutions. The drug knowledge base currently integrated 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 facilitate 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 prototypes [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 relational 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 business 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 detailed 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 Catherine Duclos from the Lim&Bio Laboratory 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. Frequency and cost of serious adverse drug reactions in a department of general medicine. Br J Clin Pharmacol 1998; 45 (3): 301–308. 2. Oliven A, Michalake I, Zalman D, Dorman E, Yeshurun 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, RosasArellano MP, Devereaux PJ, Beyene J, Sam J, Haynes RB. Effects of computerized clinical decision support systems on practitioner performance and patient 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 justified? J Am Med Inform Assoc 2004; 11 (2): 125–126. 6. Fair MA, Pane F. Pharmacist interventions in electronic 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 multicentre study of pharmacist initiated changes to drug therapy and patient management in acute care government funded hospitals. Br J Clin Pharmacol 2004; 57 (4): 513–521. 8. Leape LL, Cullen DJ, Clapp MD, Burdick E, Demonaco HJ, Erickson JI, Bates DW. Pharmacist participation 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 institutions, To Hospitals labour unions and to sociomedical establishments with a pharmacy for internal 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 validation 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 hospital. Am J Health Syst Pharm 1997; 54 (5): 545–549. 13. Mullett CJ, Evans RS, Christenson JC, Dean JM. Development 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. Evidence Report/Technology Assessment No. 132. (Prepared by the Southern California Evidencebased 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. Medicationrelated 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 implementation: 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 representation 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 modelling of clinical practice guidelines for enactment. Stud Health Technol Inform 2003; 95: 635–640. 22. LeBozec C, Jaulent MC, Zapletal E, Degoulet P. Unified 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 – EVOLUTION – OF – SIX – SIGMA – PB – Taylor & Francis. 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

© Schattauer 2011

Methods Inf Med 1/2011

Downloaded from www.methods-online.com on 2012-05-12 | IP: 82.247.116.130 For personal or educational use only. No other uses without permission. All rights reserved.

47

48

A. Boussadi et al.: A Business Rules Design Framework for a Pharmaceutical Validation and Alert System

25. Osheroff JA. Clinical Decision Support Implementer’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 Unified Software Development Process. Addison-Wesley 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-interpretable 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 proposed standardized object-oriented expression language 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 componentbased 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 interchange 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 interpretable language. AMIA 2009 Symposium Proceedings. 35. “Anonymous” Semantics of Business Vocabulary and Business Rules Specification. Document de specification 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 prescription. Methods Inf Med 1995; 34 (4): 310–317. 40. Gamma E, Johnson R, Helm R. Vissides J. Design patterns: Elements of reusable object-oriented software. 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 accessed 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 Association of Healthcare Information 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 commercial knowledge bases for clinical decision support: opportunities, hurdles, and recommendations. J Am Med Inform Assoc 2006; 13 (4): 369–371. 48. Ash JS, Gorman PN, Seshadri V, Hersh WR. Computerized 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 action 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 override 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 development, 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 development: it’s about feedback and change. Computer 2003; 36 (6): 43, 39. 60. Moxey A, et al. Computerized clinical decision support for prescribing: provision does not guarantee uptake – 17 (1): 25 – Journal of the American Medical Informatics Association (Internet). Llast accessed Jan 13, 2010. Available from: http://jamia. bmj.com/content/17/1/25.abstract 61. Linehan MH. SBVR Use Cases (Internet). In: Proceedings 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 commercial rule engine as a basis for a clinical decision support service. AMIA Annu Symp Proc 2006. pp 294–298. 63. Kashyap V, Morales A, Hongsermeier T. On implementing clinical decision support: achieving scalability and maintainability 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. Methodology 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.

Methods Inf Med 1/2011

© Schattauer 2011

Downloaded from www.methods-online.com on 2012-05-12 | IP: 82.247.116.130 For personal or educational use only. No other uses without permission. All rights reserved.

A. Boussadi et al.: A Business Rules Design Framework for a Pharmaceutical Validation and Alert System

Appendix

Fig. A-1 Business object model of the ‘To Validate Prescription’ system use case © Schattauer 2011

Methods Inf Med 1/2011

Downloaded from www.methods-online.com on 2012-05-12 | IP: 82.247.116.130 For personal or educational use only. No other uses without permission. All rights reserved.

49

50

A. Boussadi et al.: A Business Rules Design Framework for a Pharmaceutical Validation and Alert System

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, business 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 …”

Methods Inf Med 1/2011

© Schattauer 2011

Downloaded from www.methods-online.com on 2012-05-12 | IP: 82.247.116.130 For personal or educational use only. No other uses without permission. All rights reserved.