Koray Atalag MD, Ph.D National Institute for Health Innovation, University of Auckland (3/11/10, Square, 2.30)

1. From Domain Models to Advanced User Interfaces: a Case Study in Endoscopy Koray Atalag, MD, Ph.D The University of Auckland National Institute for Health Innovation & Department of Computer Science k.atalag@auckland.ac.nz Hong Yul Yang, Ph.D The University of Auckland National Institute for Health Innovation & Department of Computer Science hongyul@cs.auckland.ac.nz

2. Research Domain Digestive Endoscopy A small and manageable (niche) domain Quite invasive procedure  results need to be reliable, complete and unambiguous Good level of common medical language Worldwide accepted terminology Uniform/OO like hierarchy  Prerequisite for dynamic GUI generation

3. A Not So Pleasant Experience!

5. Terminology Standardization in Endoscopy

6. Minimal Standard Terminology for Digestive Endoscopy (MST) Started in 1990, the official terminology for World Society of Gastro-intestinal Endoscopy (OMED) A "minimal" list of terms for use in computer systems Large scale clinical validation in EU project – GASTER and an US project Represented in the NLM’s UMLS Eleven language translations! Uniform hierarchy/almost 100% structured terms and value lists covering 99% of endoscopy reports  GREAT OPPORTUNITY for automatic GUI generation

7. MST Organization

9. Past Experience GST: ‘old’ Endoscopy Reporting Application Started 1999 as commercial project; used in a large University hospital >5 years Visual Basic / MS Access Database ‘Big’ data model (termdb field) GUI built with VB IDE – static/ terms hard coded Went well initially but then…too difficult to maintain Started PhD in Information Systems; served as my research prototype I have collated all Change Requests (CR) over its usage Motivation for research: make it future-proof!

10. Research Prototype GST (Turkish GUI) Automatic report generation

11. Why openEHR? Modelling is intuitive and easy (using tools) Complexity of medical informationmultiple layers Minimize technicalhealthcare professionals Enable separation of domain knowledge from code Software can evolve with minimal programming Archetype specialisation enables backward data compatibility / semantic interoperability MST Model can be extended per local needs Multilinguality comes out of the box Clinical models automatic GUI generation

12. openEHR Multi-Level Modelling

14. Rectal exam (free text)

16. Method

17. Result

23. Templates...Bringing All Together

24. Development: GastrOS .Net and C# WinForms Application openEhrV1 .Net C# Reference Model Library(from Ocean Informatics) + extended it MST Archetypes & Templates Introduced ‘GUI Directives’ for GUI generator Wrapper + SDE Component= GST functionality Open Source (depends on Ocean C# Library!) Commercial friendly license: plugged into any HIS

25. Development Details Used MVC approach Generic GUI widgetsReference Model classes Combobox bound to DV_CODED_TEXT 4-state checkboxes for clinical findings Container items act as frames/columns/tabs Defined ‘entry points’ in application into each form; Findings button to call MST Findings GUI The only application specific aspect in project ...can be used in other similar domains (such as anatomical pathology or imaging)

26. A Look at GastrOS GUI formAspects(width=800, height=600) break(tab) isOrganiser showAs(splash, smart) isCoreConcept

27. GUI Directives  10 of them; all generic  with some parameters isOrganiser(g): when this is set then it will be shown as a group which will contain all its children (i.e. as a frame, form etc.). A container object will simply be ignored when this is not set. isCoreConcept (g): This is an abstract concept; but we can say that Core Concepts are real-world entities which we can talk about their absence (i.e. a clinical finding, a disease but not tumour grade or physical examination). The directive depicts whether a node with all its children (if any) shall be handled and repeated as a whole in an archetype (i.e. makes sense together such as a clinical finding with other attributes defining its nature). When the node and/or its children are selected, its presence information is stored in the corresponding ELEMENT node which records this (i.e. in MST Findings archetypes [Present?] node).

28. GUI Directives (cont.) showAs (form|splash,modal|modeless|smart) (g): Determines the behaviour when node's values or children are displayed. The node's label is shown as a reference (i.e. link, button or similar) and the contents will be shown on another modal form - (form) or on a pop-up form (splash). (smart) is a special type of modeless form which closes when loses focus). If this is a leaf node (i.e. ELEMENT) then its values will be listed to be selected (depending on the cardinality and occurrences allowed in the archetype single or multiple selection will be possible. If this is not a leaf node then the node and all its children will be displayed using regular display options. break (next|parent|tab) (g): causes the node and rest of the model to appear in the next column but within the same organiser (next); in the next column within a separate organiser which is semantically the continuation of current one (parent); in a new tab within the same form (tab).

29. GastrOS Templates

30. Big Picture: Maintainability Assessment ISO/IEC 9216 and 25000 Software Quality std. External QualityMaintainability characteristic; Changeability Subcharacteristic Two metrics: (mainly look at maintenance tasks) Change cycle efficiency (CCE)time from initial request to resolution of the problem Modification complexity (MC)sum of time spent on each change per size of software change divided by total number of changes 10 CR – real ones from GST usage SVN + JIRA tools for documentation + measure

31. Stage-2 Results CCE 9 times less effort overall to modify GastrOS MCthe changes were on average 7 times less complex

32. Conclusion Dynamic GUI generation requires structured domain knowledge; terminology/ontology openEHR clinical models + GUI Directives is an effective means to provide dynamic GUI All GUI Directives turned out to be ‘generic’  Assessed software maintainability formally; significant GUI component More work is needed to test in other domains (and probably add/refine GUI directives)

33. Questions?