URUZ3: A formal- specification tool for acquisition and maintenance of clinical guidelines Department of Information Systems Engineering Faculty of Engineering Ben-Gurion University of the Negev Student :Erez Shalom Advisor : Prof.Yuval Shachar

The task of authoring the Knowledge will include a two-phase process: -first phase (typically performed by a medical expert) supports semantic mark-up and structuring of free-text guidelines -second phase (typically performed by a knowledge engineer) converts the semi-structured guideline into a formal guideline- specification language, ASBRU. Current work on URUZ has graphical and other limitations, therefore, the structuring is performed until the semi-structured only, in cumbersome,not intuitive way. URUZ Background

URUZ3 requirements Graphical and intuitive WinForm tool for guideline structuring Enable structuring for semi and formal language every element in the formal-language will have special graphical representation, emphasizing its special characteristics(e.g plan-body builder,condition builder) Support multi-ontology for mark-up Part of DeGeL’s framework the tool will also involve interaction with other tools (IDAN’s frame work)

URUZ3 & IDAN framework

Starting URUZ3 When starting URUZ3,before creating a GLDoc,one can choose the ontology to based on. Current supported ontologies are Asbru,GEM

URUZ3 main interface: About the Structure-level Views tree: There is view for each structure-level. Thus, when expert structure a GLDoc, she can choose a view of structuring level.the tree composed from relevant knowledge roles of the current structuring level(e.g. knowledge roles as “returns” and “arguments” will be shown just in Full-Asbru view –see slide 8).The expert push the button for each view. the most right button is hybrid view. See more explanation in the comments part Here,an expert dragged the “filter-precondition” knowledge role to the edit area. because the current structuring level is “text”, an html editor tab control generated, enables drag& drop of text portions from the GL source ( “Diagnosis and management of hypertension”). Free text and modifications can be done using the editor tool -bar

SST view-”filter precondition” example : Note that because the structure level view is SST,every knowledge role which belongs to this level (e.g not “arguments”) has an “SST” node (and icon) enabling further structuring in SST.Here,an expert dragged the Text “filter-precondition” to the view area and the “SST” knowledge role to the edit area ; then he can open the condition builder for the semi-formal structuring.

Full structured view-”filter precondition” example : In the Full structure view every knowledge role which is belong to this level (e.g “arguments”,”value def”) have “Full” node(and simbolic image) enabling further structuring in Full Asbru. Here,an expert dragged the Text “filter-precondition” to the view area and the “Full” knowledge role to the edit area –then he can constarct the condition in IDAN language,thus the condition is represented in his formal structure.

SST view-”deafults” example : The expert dragged the “SST” node of “deafults “ knowledge role to the editing area.Thus the generated tab is according to Asbru semantics in the context of that knowledge role. when pressing the buttons a different GUI is generated for each attribute, enable further structuring of the element.for example,a control for specifing time –annotation or duration can be generated according to the user action.

SST view-”Plan-Body” example : From the SST level of Plan-body,the expert can open the Plan-body builder (explain in detail in slid 12-17).Thus, the expert can create hierarchy of plans for the current plan.

Hybrid view-”deafults” example : Note that the tree includes all the knowledge roles from all the levels. Here,the SST level of the “obtain values” knowledge role used for structuring the FULL level of “Returns” knowledge role. By selecting a plan in the PB tree (we have plans specification after we used the PB builder), we can structure a knowledge role in context of the selected GL.

Plan-Body builder :Expressing the Procedural Knowledge This task will be perform in several steps, guiding the physician, step by step, to structure the guideline’s procedural knowledge In the beginning of the process,the medical tasks hierarchy will be defined and afterwards the order between the them. Thus, when the general concept of the plan is discovered, the physician can continue with defining the less intuitive characteristics of the procedural knowledge. In this primary prototype the first two steps were implemented

Semantic Types Reference Types Control Types Parent TextChild Text Order Between Plans Plans Tree Plans Tab

Drag And Drop Plans Root Text (Source in this case)Free Text for selected Plan selected Plan Generated Tree of plans Check if mandatory plan

Parallel Order selected Dragged text to child plan from Parent text Renamed Plan

New tab for expanded plan Every new level has at least 2 general plans Condition Type Previous Child Text become Parent text in this level Generated tree

Convert to semantic type mechanism

Converted plan Condition Property – Opne Expression Builder Condition Text

Expression Bulider open to specify a condition base (or not) on the text

Double Click Expand the (plan (has dash boredr Convert the general into drug type

The Expression Choises Default

Drag a Choice and add to the cases collection Back to Parent Level

Reference Types