390 likes | 478 Views
GreEd and its Rules Representation. (GreEd and its Creed). Hemant Shah M.D., M. Surg. Sr. Research Informatician, CSRI Henry Ford Health System hshah2@hfhs.org. What is GreEd?. G raphical R ule E lements Ed itor A tool to author and edit rules
E N D
GreEd and its Rules Representation (GreEd and its Creed) Hemant Shah M.D., M. Surg. Sr. Research Informatician, CSRI Henry Ford Health System hshah2@hfhs.org
What is GreEd? • Graphical Rule Elements Editor • A tool to author and edit rules • Easy to use graphical representation of rules • Drag and drop is all you need • Internal rule syntax inspired by LISP • Allows testing of rules from within the environment • Currently in use for Proteus based tools • Architecture extensible to support creation of rules in multiple languages • (e.g., Arden Syntax, Gello Expressions, Java, RuleML, Jess, JBoss Rules etc.) • Source soon to be made available under a liberal Open Source License (LGPL or similar)
Rule – General Aspects • Left Hand Side of a Rule is a boolean expression (e.g. Age more than 45) • LHS expression may contain sub-expressions • The Right Hand Side varies but LHS is similar in most rules • Therefore suitable for standardization
The GreEd LHS (Criterion) Structure • Rule Criterion structure similar to LISP syntax and First Order Predicate Expressions As commonly expressed Age >= 45 Expressed in a LISP-like Syntax >=(Age, 45) Represented as a Tree OPERATOR >= Operand Age 45
LISP like structure allows: • A tree like structure • Each branch is an operator/function which can be: • Simple mathematical operation • Boolean operation • Complex function • A branch may have other branches or leaves • Each leaf is an operand (atom) which can be: • Common data element or Variable • A possible/permissible value for a CDE • A constant/literal • A common syntax for Operators & Functions As commonly expressed Age >= 45 Expressed in a LISP-like Syntax >=(Age, 45) Represented as a Tree OPERATOR >= Operand Age 45
LHS of A Rule LHS AND OR >= > = = Age 45 Polydipsia true FBS 120 Race Indian (Age >= 45) AND ((Polydipsia = true) OR (FBS > 120) OR (Race = Indian)) AND( >=(Age, 45), OR( =(Polydipsia, true), >(FBS, 120), =(Race, Indian))) Expressed in a LISP-like Syntax
Rule RHS = Diabetes Suspicion true Adding the RHS makes it a Complete Rule LHS AND OR >= > = = Age 45 Polydipsia true FBS 120 Race Indian (Age >= 45) AND ((Polydipsia = true) OR (FBS > 120) OR (Race = Indian)) Then Diabetes Suspicion = true AND( >=(Age, 45), OR( =(Polydipsia, true), >(FBS, 120), =(Race, Indian))) Expressed in a LISP-like Syntax -> Assign true to Diabetes Suspicion
Rule RHS = Diabetes Suspicion true The Data Elements Can Be Standardized LHS AND OR >= > = = Age 45 Polydipsia true FBS 120 Race Indian ISO/IEC 11179 Data Elements
ISO/IEC 11179 Standard • Specifies standard structure for Common Data Elements (CDEs) and CDE Repositories • Each part of a data element can be linked with a concept in a vocabulary/ontology, allowing the semantics also to be standardized • Each data element can be part of an information model specified in UML • Shows a possible way out of the ‘curly braces’ problem • A cornerstone of interoperability in the caBIGprogram of NCI (caBIG has developed an open access, shared, data element repository – caDSR) • A standard that Medical Informatics ignored – Deserves a closer look
Data Element Name Object Class Property Representation Qualifier 1 Qualifier 1 Qualifier 1 Qualifier 2 Qualifier 2 Qualifier 2 Qualifier n Qualifier n Qualifier n Value Domain Definition Data Type Permitted Values ID Value Item 1 Unit Other Attribute 1 Value Item 2 Value Item 3 Other Attribute 2 Value Item n Other Attribute n ISO/IEC 11179 Data Element
HFHS Diabetes Example 1 or more admissions with ICD9 = 250.x = true 1 or more pharmacy claims with diabetes therapeutic class Data suggests diabetes = OR true More than 1 outpatient visits with ICD9 = 250.x = true Age appropriate Age >= Candidate suitable 18 AND Enrolled = false Not enrolled Has Primary Care Physician = true OR More than once seen by Endocrinologist (s) in 2 years Diabetes care provider available = true
Example of Calculation: Mean Arterial Pressure (MAP) Mean Arterial Pressure = / + x Diastolic 2 Systolic 3 ((2 x Diastolic) + Systolic) / 3)
Before the Demo… • A caveat: Still in Development • A word about the Input for GreEd: Context • What is a GreEd Context? • A collection of Inputs and Outputs (as data elements) for which the rules are to be created • Each context has enough information for GreEd to allow creating rules
Symptoms of Diabetes Inputs Output A Context Example: “Symptoms of Diabetes” Context Data Elements
Example: “Symptoms of Diabetes” Rule If Polydipsia = True AND Polyuria = True AND Unexplained Weight Loss = True Symptoms of Diabetes = True
HgbA1c Rule • HgbA1c Rule 1 If Months since HgbA1c >= 6 Overdue for HgbA1c • HgbA1c Rule 2 If Months since HgbA1c <= 6 AND Months since HgbA1c > 5 Almost due for HgbA1c • HgbA1c Rule 3 If Months since HgbA1c <= 5 AND Months since HgbA1c > 3 AND HgbA1c > 7 % HgbA1c is high and overdue for HgbA1c • HgbA1c Rule 4 If Months since HgbA1c < 3 AND HgbA1c > 7 % HgbA1c is done within 3 months but is high
GreEd Syntax as XML (simplified) • <if> • <Condition> • <and> • <greaterThan> • <atom> • <objectClass> patient </objectClass > • <property> months_since_HgbA1c </property> • </atom> • <atom> • <value> 3 </value> • </atom> • </greaterThan> • <lesserThanOrEqual> • <atom> • <objectClass> patient </objectClass > • <property> months_since_HgbA1c </property> • </atom> • <atom> • <value> 5 </value> • </atom> • </lesserThanOrEqual> • <greaterThan> • <atom> • <objectClass> patient </objectClass > • <property> HgbA1c </property> • </atom> • <atom> • <value> 7 </value> • </atom> • </greaterThan> • </and> • </Condition> • <Conclude> • <atom> • <objectClass> eligibility </objectClass > • <property> status </property> • <value> true </value> • </atom> • </Conclude> • </if> Operands Operators ArdenML - Level 4 Encoding (Matt Sailors) Level 4 encoding structures Arden Syntax down to the level of operators and operands.
Diabetic Foot Screening Rule • Foot Exam Rule If Double Amputee = false AND Months since Foot Complete Exam > 12 OR Months since Foot Pulses Exam > 12 OR Months since Foot Sensation Exam > 12 OR Months since Foot Visual Exam > 12 No diabetic foot exam in past year
Operators/Functions Data Elements Literals/Values
Class Diagram for Rule (Simplified) • Each rule has a LHS and RHS • Each LHS is an expression • Each expression consists of an operator and more than one expression units, which may be expressions or CDE values pair. Each Value is one of the values permitted for the CDE. • Value is one of the possible or permissible values
Advantages of the GreEd Approach • Human and Machine Interpretable • Scalable, Hierarchical Representation • Reusable Criteria • Editability • Eliminate the need for Expert-Engineer-Developer collaboration cycles
Advantages of the GreEd Approach • Standardization - The structure allows translating into different formats. • Examples: • Arden Syntax • GELLO • RuleML • Programming language code • Morningside Syntax?
<Imp> <head> <Atom> <Rel>own</Rel> <Var>person</Var> <Var>object</Var> </Atom> </head> <body> <And> <Atom> <Rel>buy</Rel> <Var>person</Var> <Var>merchant</Var> <Var>object</Var> </Atom> <Atom> <Rel>keep</Rel> <Var>person</Var> <Var>object</Var> </Atom> </And> </body> </Imp> Imp = Implies = Rule Head = RHS of Rule Body = LHS of Rule Rel = Relation = Function/Operator The GreEd syntax as Standard RuleML
Advantages of the GreEd Approach • Semantic Organization: Use of ISO/IEC 11179 standard based data elements makes possible: • Dynamic Semantic Organization of Rules • Examples: • Grouped by clinical subject areas like Neurology, Ophthalmology, Gastroenterology etc. • Grouped by clinical categories, e.g., symptoms, signs, lab results etc. • Semantic Searches • Example Queries: • Give me all the rules that: • Conclude presence of diabetes • Determine patient eligibility = true • Use weight loss as an antecedent • Utilize ‘disease = papillary serous adenocarcinoma of ovary’ and ‘duration of disease’ as facts • Utilize Eye conditions (returns rules that use diabetic retinopathy, cataract, corneal ulcer etc.)
Advantages of the GreEd Approach • CDE based expressions will facilitate: • Maintenance – any change in a CDE can be quickly recognized and the criteria/rules can be modified and vice versa • Automation • Examples: • Alerts from the applications in which CDEs are used to automatically detect and grade adverse events • Automatically Generated Processes and Forms to lead the user to the Inference • Natural language translation of rules
Future Plans: • Full Use of ISO/IEC 11179 data elements for conditions and inferences, including accessing repositories like caDSR • Semantic organization and search capabilities • Completeness checks on rules • Semantic aids and constraints to create rules • Rule repository related features • New operators like “n of m” • Extensibility • New logical or math operations can be added • New Languages plug ins
Other 1 Contains Toggle button Contains Toggle button Menu Bar Main Toolbar + main information about KC / Context etc Main (editing) Panel Rule Panel Toolbar Logic Maintain Trigger Other 2 Editing panel Toolbar Operators/Functions palette Rule Tree Toolbar Alerts Zone (2 lines of text) Status Zone (2 lines of text) Code Panel Info Panel Java Arden RuleML User
Menu Bar Context Inputs Output Main Toolbar + main information about KC / Context etc Other 1 Main (editing) Panel Rule Panel Toolbar Logic Maintain Trigger Other 2 Editing panel Toolbar Operators/Functions palette Rule Tree Toolbar Extension B Extension A Alerts Zone (2 lines of text) Status Zone (2 lines of text) Java Arden RuleML User GreEd Architecture and Components GreEd Rules Repository CDEs ISO/IEC 11179 based CDE Repository Translator GRE Rule - Format B ________ __ -_____ ____ _______ _____ _____ _____ _____ ____ ___ ___ ____ Rule - Format A ________ __ -_____ ____ _______ _____ _____ _____ _____ ____ ___ ___ ____
Proteus Environment Proteus GreEd Inference Tool • Accepts KCs with Standard DEs (ISO/IEC 11179) • Returns Proteus Inferences BeanShell • Open source tool • Allows treating Java as a scripting language GreEd Rule Engine - Current Environment
Proteus Environment Proteus GreEd Inference Tool • Accepts KCs with Standard DEs (ISO/IEC 11179) • Returns Proteus Inferences GreEd Environment GreEd Rule Engine • Accepts Generic Data Elements • Returns result as Generic Data Elements BeanShell • Open source tool • Allows treating Java as a scripting language GreEd Rule Engine - MI Modification
Rules Engine Rules Repository Standard Interface Extended Interface Interface Access Reference Rules System ISO/IEC 11179 based CDE Repository Clinical System Rule Editing Environment CDEs
GreEd Interface Operators/functions Available to Drop in Rule Criteria Context Information All Rules for the Context Selected Rule as a Tree (note organization by operators) Editing Panel Displaying the Selected Rule Output Panel Displaying the Selected Rule as Java Code Description Tabs for Other Views of the Selected Rule
The Common Data Element For the RHS of the Rule Diarrhea Common Data Elements That form the LHS of the Rule Possible Values of RHS data element
Increase of 4 - 6 stools per day over baseline • IV fluids indicated <24hrs • moderate increase in ostomy output compared to baseline • not interfering with ADL Diarrhea AE Grade 2