Drools – Diabetes Phenotype Identification June 30, 2011 Jeffrey Ferraro, PhDc1 Herman Post, MS1 Darin Wilcox, MS1 1Intermountain Healthcare, Salt Lake City, Utah

Discussion Points Drools Background Drools Inference & Workflow Capabilities Describe Drools Inference Execution Model Exam the Drools Rule Semantics High Level Architecture Diabetes Workflow Perceived Benefits Future Directions

Drools Framework Business Logic Integration Platform Framework Supports Production Rule Inference Engine Workflow (jBPM ≡ Workflow Engine) Complex Event Processing (CEP) Planner – Optimization of NP-hard problems in workflow (i.e. time scheduling)

Drools History SourceForge Open Source in 2001 Licensed under Apache Part of JBoss Project in 2005 RedHat acquires JBoss in 2006 JBoss Rules (Commercially Supported Version) Published Books JBoss Drools Business Rules, Paul Browne Drools JBoss Rules 5.0 Developer's Guide, Michal Bali Business Process Management with JBoss jBPM: A Practical Guide for Business Analyst, Matt Cumberlidge

Drools Productivity Tools Guvnor – Business Rules Management System (BRMS) Authoring Testing Versioning Access Control of Rules & Workflow Eclipse plugins Authoring rules and workflow Integration into Guvnor Decision Tables Rule or Workflow Testing Structures

Authoring Languages Drools Rule Language (DRL) – Native Rule Syntax Two Language Dialects MVEL – Expression Language Java – Programming Like Business Process Management Notation v2 (BPMN2) Workflow Authoring Domain Specific Language Creation (DSL) Human Readable Grammars *Production Rules Definition Only

Benefits of a Rules Engine Declarative Programming Model (‘what’ not ‘how’) Promotes Separation of Business Logic and Data Loose Coupling of Business Logic (Reusability) Promote Centralization of Knowledge Productivity: Knowledge Engineering Tools Strive for Understandable Rules (Human Readable?) Shareable Rules Facilitated by Common Fact Model

Drools Inference Engine Represent Knowledge thru Production Rules Forward Chaining Inference Model Rule Matching(‘how’): Rete Algorithm & Leaps “Data Driven” – Reactionary Inference Model Facts Asserted into Working Memory Rule Propagation takes Place Legible Rules Schedule for Execution Consequence(s) Realized (Results) Backward Chaining Inference Model (future support) “Goal Driven” (Why Questions) Start with Conclusion  Inference to Satisfy Conclusion

Drools Workflow Goal of Workflow - combine tasks into an understandable process Supports task sequencing Promotes understanding thru process visualization - graphical modeling support Provides seamless integration of rules and flow Supports WS HumanTask 1.0 implementation State Management Supports Pluggable Work Items Domain-specific Definition Declarative Model (‘what’, not ‘how’) High-level Definition (no code)

Drools Inference Architecture Inference Execution Model Define a Knowledge Base Compiled Rules (*Expensive Operation) Produces Production Memory Extract Knowledge Session from Knowledge Base Insert Facts (data) into Knowledge Session  “Agenda” Fire Rules (*Race Conditions/Infinite Loop – ouch!) Retrieve End Results

DRL Basic Rule Semantics rule <name> when {Condition} <(1..n) facts in Working Memory OR data from external sources, matches this rule> then {Consequence} <update, insert or retract some facts in Working Memory OR set a parameter (end result)> end

Example DRL Rule rule "Glucose <= 40, Insulin On“ when $msg : GlucoseMsg(glucoseFinding <= 40, currentInsulinDrip > 0 ) then glucoseProtocolResult.setInstruction(GlucoseInstructions.GLUCOSE _LESS_THAN_40_INSULIN_ON_MSG); end

Example DRL Rule {Rule Name} rule "Glucose <= 40, Insulin On“ when $msg : GlucoseMsg(glucoseFinding <= 40, currentInsulinDrip > 0 ) then glucoseProtocolResult.setInstruction(GlucoseInstructions.GLUCOSE _LESS_THAN_40_INSULIN_ON_MSG); end {Class Getter Method} {binding} {Java Class} Parameter {Java Class} {Class Setter Method}

Current Architecture Business Logic Clinical Element Database Data Access Layer Business Logic Transformation Layer Inference Engine (Drools) List of Diabetic Patients Service for Creating Output (File, Database, etc) Transform physical representation  Normalized logical representation (Fact Model)

Diabetes Workflow

Benefits Organized representation of knowledge & process Rules and Workflow - accessibility by clinicians Facilitates collaborative authoring Potential for knowledge sharing thru common fact model BPMN represents an explicit, declarative stateful programming model Tight integration of rules and workflow

Future Directions Define a fact model that can be shared across organizations Better understand use of Rules vs. Workflow Explore Domain Specific Languages (DSL) Evaluate performance & scalability Define a Rules and Workflow sharing model

Collaboration & Exploration Drools Knitting Group (hosted by Intermountain Healthcare) Participants University of Utah Duke University Naval Medical Center (Emory Frye) Shared Experimental Environment

Thank You!