URUZ3: A formal- specification tool for acquisition and maintenance of clinical guidelines

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

2. URUZ Background • 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.

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

4. URUZ3 & IDAN framework

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

14. URUZ3 main interface: 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 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

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

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

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

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

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

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

21. Plans Tab Order Between Plans Semantic Types Reference Types ControlTypes Plans Tree Parent Text Child Text

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

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

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

25. Convert to semantic type mechanism

26. Condition Property – Opne Expression Builder Converted plan Condition Text

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

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

29. Choises Default The Expression

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

31. Reference Types