1 / 39

GreEd and its Rules Representation

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

Download Presentation

GreEd and its Rules Representation

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. 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

  2. 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)

  3. 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

  4. 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

  5. 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

  6. 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

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

  8. 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

  9. 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

  10. 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

  11. Examples

  12. 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

  13. Example of Calculation: Mean Arterial Pressure (MAP) Mean Arterial Pressure = / + x Diastolic 2 Systolic 3 ((2 x Diastolic) + Systolic) / 3)

  14. 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

  15. Symptoms of Diabetes Inputs Output A Context Example: “Symptoms of Diabetes” Context Data Elements

  16. Example: “Symptoms of Diabetes” Rule If Polydipsia = True AND Polyuria = True AND Unexplained Weight Loss = True  Symptoms of Diabetes = True

  17. 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

  18. 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.

  19. 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

  20. Operators/Functions Data Elements Literals/Values

  21. 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

  22. Advantages of the GreEd Approach • Human and Machine Interpretable • Scalable, Hierarchical Representation • Reusable Criteria • Editability • Eliminate the need for Expert-Engineer-Developer collaboration cycles

  23. Advantages of the GreEd Approach • Standardization - The structure allows translating into different formats. • Examples: • Arden Syntax • GELLO • RuleML • Programming language code • Morningside Syntax?

  24. <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

  25. 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.)

  26. 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

  27. 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

  28. 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

  29. 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 ________ __ -_____ ____ _______ _____ _____ _____ _____ ____ ___ ___ ____

  30. 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

  31. 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

  32. Thanks

  33. Additional Slides(Examples, Screenshots)

  34. 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

  35. 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

  36. New GUI framework (very early)

  37. 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

  38. 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

More Related