From openEHR Domain Models to Advanced User Interfaces: a Case Study in Endoscopy
0 likes278 views
The document discusses the development of a dynamic GUI generation system for digestive endoscopy reporting, utilizing standardized terminology and openEHR models for semantic interoperability. It outlines the challenges and solutions in creating a user-friendly interface that can adapt to changes in medical information while ensuring maintainability and extensibility. The findings highlight the effectiveness of applying structured domain knowledge and generic GUI directives in improving the overall software maintainability in medical applications.
![GUI Directives 10 of them; all generic with some parametersisOrganiser(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).](https://image.slidesharecdn.com/p17atalag-101105002149-phpapp01/85/From-openEHR-Domain-Models-to-Advanced-User-Interfaces-a-Case-Study-in-Endoscopy-27-320.jpg)
From openEHR Domain Models to Advanced User Interfaces: a Case Study in Endoscopy
- 1. From Domain Models to Advanced User Interfaces: a Case Study in EndoscopyKoray Atalag, MD, Ph.DThe University of AucklandNational Institute for Health Innovation& Department of Computer Sciencek.atalag@auckland.ac.nzHong Yul Yang, Ph.DThe University of AucklandNational Institute for Health Innovation& Department of Computer Sciencehongyul@cs.auckland.ac.nz
- 2. Research DomainDigestive EndoscopyA small and manageable (niche) domainQuite invasive procedure results need to be reliable, complete and unambiguousGood level of common medical language Worldwide accepted terminologyUniform/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 systemsLarge scale clinical validation in EU project – GASTER and an US projectRepresented in the NLM’s UMLSEleven language translations!Uniform hierarchy/almost 100% structured terms and value lists covering 99% of endoscopy reports GREAT OPPORTUNITY for automatic GUI generation
- 9. Past ExperienceGST: ‘old’ Endoscopy Reporting ApplicationStarted 1999 as commercial project; used in a large University hospital >5 yearsVisual Basic / MS Access Database‘Big’ data model (termdb field)GUI built with VB IDE – static/ terms hard codedWent well initially but then…too difficult to maintainStarted PhD in Information Systems; served as my research prototypeI have collated all Change Requests (CR) over its usageMotivation for research: make it future-proof!
- 10. Research PrototypeGST(Turkish GUI)Automatic report generation
- 11. Why openEHR?Modelling is intuitive and easy (using tools)Complexity of medical informationmultiple layersMinimize technicalhealthcare professionalsEnable separation of domain knowledge from codeSoftware can evolve with minimal programming Archetype specialisation enables backward data compatibility / semantic interoperabilityMST Model can be extended per local needsMultilinguality comes out of the boxClinical models automatic GUI generation
- 13. Specialisation of MST ArchetypesALL BACKWARD COMPATIBLE semantic interoperability!FindingsStomach(normative)FindingsStomach(fixes+extensions)Local specialisationPublished versionGastrOS FindingsStomachIntl. UpdateRapid Urease
- 14. Rectal exam (free text)
- 16. Method
- 17. Result
- 18. etcModelling GastrOSNumerous Archetypes (as per MST):Examination CharacteristicsFindings / Anatomical sitesDiagnosisProcedures / ComplicationsMany detailed archetypes are ‘structural’; i.e. Can be plugged into Entry types (slot archetypes)3 Templates for each exam type (EGD, Colonoscopy & ERCP)
- 24. Development: GastrOS.Net and C# WinForms ApplicationopenEhrV1 .Net C# Reference Model Library(from Ocean Informatics) + extended itMST Archetypes & TemplatesIntroduced ‘GUI Directives’ for GUI generatorWrapper + SDE Component= GST functionalityOpen Source (depends on Ocean C# Library!)Commercial friendly license: plugged into any HIS
- 25. Development DetailsUsed MVC approachGeneric GUI widgetsReference Model classesCombobox bound to DV_CODED_TEXT4-state checkboxes for clinical findingsContainer items act as frames/columns/tabsDefined ‘entry points’ in application into each form; Findings button to call MST Findings GUIThe only application specific aspect in project...can be used in other similar domains (such as anatomical pathology or imaging)
- 26. A Look at GastrOS GUIformAspects(width=800, height=600)break(tab)isOrganisershowAs(splash, smart)isCoreConcept
- 27. GUI Directives 10 of them; all generic with some parametersisOrganiser(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).
- 30. Big Picture: Maintainability AssessmentISO/IEC 9216 and 25000 Software Quality std.External QualityMaintainability characteristic; Changeability SubcharacteristicTwo metrics: (mainly look at maintenance tasks)Change cycle efficiency (CCE)time from initial request to resolution of the problemModification complexity (MC)sum of time spent on each change per size of software change divided by total number of changes10 CR – real ones from GST usageSVN + JIRA tools for documentation + measure
- 31. Stage-2 ResultsCCE 9 times less effort overall to modify GastrOSMCthe changes were on average 7 times less complex
- 32. ConclusionDynamic GUI generation requires structured domain knowledge; terminology/ontologyopenEHR clinical models + GUI Directives is an effective means to provide dynamic GUIAll GUI Directives turned out to be ‘generic’ Assessed software maintainability formally; significant GUI componentMore work is needed to test in other domains (and probably add/refine GUI directives)
- 33. Questions?