Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Why ICT Fails in Healthcare: Software Maintenance and Maintainability


Published on

This presentation was for a SERG seminar at the University of Auckland Department of Computer Science. I present why software maintenance is a barrier for adoption of IT in healthcare and the maintainability aspects based on ISO/IEC 9126 software quality standard quality model. I then present the preliminary results of my research here.

Published in: Education
  • Be the first to comment

Why ICT Fails in Healthcare: Software Maintenance and Maintainability

  1. 1. Why IT Fails in Healthcare? <br />A look at Software Maintenanceand Maintainability Aspects<br />Koray Atalag, MD, PhD23 Mar 2010<br />
  2. 2. Agenda<br />A look at Health IT<br />Essential difficulties and implications<br />Health Informatics – directions<br />Maintenance burden in HIS<br />openEHR Paradigm<br />My research framework<br />Development work<br />Measurement & Evaluation<br />Results<br />Discussion & Conclusion<br />
  3. 3. Healthcare – Burning Issues<br />Cost increasing rapidly<br />16% GDP in US, ~8-9 in EU & NZ (Ref: OECD)<br />Quality ? (far from measuring effectively)<br />Safety (you don’t wanna know):appx 90,000 people die each year in US due to preventable medical errors! (Ref: Institute of Medicine)<br />Equity / Accessibilitybig differences related with geography, political, socio-economic status<br />
  4. 4. Health IT – What is it all about?<br />Health Information Systems (HIS): <br />ProviderGP systems, Hospital Information Systems, LIS, RIS, CIS, etc. etc.<br />Regional/National PHO, DHB, NHI, ACC etc.<br />Consumer oriented<br />PHR: Microsoft HealthVault, Google Health, other. <br />Patient portals:, The <br />Research related Genome DB, Medline, <br />Health Computational Systems: CT, MRI, ECG etc.<br />Health Communication Systems: HealthLink, NPI, DICOM<br />
  5. 5. Essential Difficulties<br />Breadth and Depth of Medical Domain<br />A medical student learns about 6000 new concepts (and sleeps much less than others!)<br />>600,000 concepts, 1.2m relationships in SNOMED<br />Complexity of concepts and processes<br />Gene>Structure>Function? + Environment+Luck<br />Variability in Medical Practice<br />Medical conduct changes acc. to time/person and across different organisations and jurisdictions <br />
  6. 6. Health Informatics<br />Medical Informatics<br /> Nursing informatics<br />Bioinformatics<br />Biomedical Informatics<br />HEALTH INFORMATICS:<br />“ Health Informatics is the science and practice around information in health that leads to informed and assisted healthcare.”<br />HISO – Australia<br />$mostly public funding & secondary care (hospitals)$20b stimulus package for health IT in US£70b NHS CfH and Canada Health Infoway Project<br />
  7. 7. Tackling These Difficulties?<br />Standardised terminology<br />Machine processable biomedical ontology<br />Clinical guidelines & Decision Support<br />Functional and Technical Standards: HL7, CEN/ISO, IEEE, ASTM, OMG – mostly open<br />Open Source tools and libraries<br />EHR Architectures<br />Tools and methodologies to effectively use IT in healthcare: mHealth, VR, telehealth, robotics<br />
  8. 8. Implications on Health IT<br />Low market penetration (AVIS/ Visa/Foodtown)<br />Increased cost: many projects either fail or over budget/schedule<br />Decreased satisfaction<br />Delivering on expectations? Improving healthcare?<br />*** Maintenance & Interoperability major issues <br />
  9. 9. Maintenance of HIS<br /><ul><li>Constitutes the majority of development costs
  10. 10. Degrades overall quality / longevity / satisfaction</li></ul>Source of problem change in domain related requirements (mostly fxnal)<br />How?<br /><ul><li>Incomplete / wrong req. at outset
  11. 11. New / no longer valid requirements</li></ul>Why?<br /><ul><li>Essential + handover
  12. 12. Volatility of domain concepts & processes</li></li></ul><li>An Important “bottleneck”<br /><ul><li>Cognitive friction /limits to </li></ul> human communication<br /><ul><li> Unknown requirements
  13. 13. Wrong requirements</li></ul>Changing requirements?<br />“handover”<br />
  14. 14. The “handover”...<br />Isn’t this the reality in health IT?<br />So far so good...<br />Not only the body of knowledge can only partially be “handed” over,<br /> but also it might just be “too much to handle”:<br /><ul><li> Techiesnature of Biomedical sciences
  15. 15. Clinicianslack of technical understanding: practical limitations of IT can be hard for a clinician to understand "if it can be done on Star Trek, why not here" syndrome</li></li></ul><li>My Past Experience<br /><ul><li>Developing HIS since 1995
  16. 16. Own company, employee, academician, freelance consultant and contractor
  17. 17. Main problem=maintenance
  18. 18. Case study: Endoscopy Reporting Application
  19. 19. Started 1999 as commercial project
  20. 20. Went well initially but then….
  21. 21. Became academic and served as PhD prototype
  22. 22. I have collated all CR over its usage
  23. 23. Motivation for my thesis and research</li></li></ul><li>Research Prototype<br />GST<br />Automatic report generation<br />
  24. 24. openEHR Formalism<br /> Complete set of engineering specifications for EHR Architecture and HIS development<br /> Open Access – not for profit Foundation<br /> Adopted by ISO & CEN (13606)<br /><ul><li>Separate tasks of developers & domain experts
  25. 25. Separate domain knowledge from software code </li></ul>DSL + MDA essentially; differences:<br /><ul><li>A reference model (RM)
  26. 26. Models structure RM Classes and puts constraints on runtime Objects</li></li></ul><li>
  27. 27. openEHR Foundation<br /><ul><li>Non-profit organisation based at University College, London (UCL)
  28. 28. Established by UCL and Ocean Informatics in 2000 to own the IP
  29. 29. 800+ Members from 71 countries
  30. 30. All specifications & schemas publicly available
  31. 31. Software open source (GPL, LGPL, MPL)</li></li></ul><li>Key Innovations<br />“Multi-level Modelling” – separation of software model into distinct layers:<br />1) Technical information model (generic)<br />2) Concept models: Archetypes (domain-specific)<br />3) Terminology/Ontology (SNOMED etc.)<br /><ul><li>Software code is based on only the first layer
  32. 32. Minimal ‘handover’
  33. 33. Driven by Archetypes in run-time
  34. 34. High level semantics delegated to terminology</li></li></ul><li>Multi-Level Modelling<br />
  35. 35. openEHR Platform<br />Queries<br />Health Integration <br />Platform<br />Archetypes<br />Health Information Platform<br />EQL<br />TOM<br />Application Development <br />Platform<br />Knowledge Management <br />Platform<br />AOM<br />ADL<br />Templates<br />Reference <br />Model<br />
  36. 36. How it works?<br />
  37. 37. Current openEHR Specifications<br />
  38. 38. Anatomy of DV_TEXT Data Type<br />
  39. 39. Domain Specific Aspects of RM<br />
  40. 40. EHR<br />Folders<br />Compositions<br />Sections<br />Entries<br />Clusters<br />Elements<br />Data values<br />Logical building blocks of EHR<br />
  41. 41. Archetypes?<br />Constraints on an information model<br />Structural constraints<br />List, table, tree<br />What labels can be used<br />What data types can be used<br />What values are allowed for these data types<br />How many times a data item can exist?<br />Whether a particular data item is mandatory<br />Whether a selection is involved from a number of items/values<br /><ul><li>Used by systems to control creation and validation of data, and to perform querying</li></li></ul><li>Archetypes: a clinical model<br />
  42. 42. Anatomy of an Archetype<br />
  43. 43. Archetype Definition Language (ADL)<br />OCL<br />+<br />DDL<br />
  44. 44. My Research Framework<br />Modelling of Endoscopy Domain<br />Stage-1:<br />SRS based on previous app (GST)<br />Develop openEHR based GastrOS<br />Stage-2:<br />Select CR from past usage of GST <br />Implement in GastrOS + check (repeat for some) in GST<br />Determine metrics & measure<br />Stage-3:<br />New CR<br />Implement changes in both applications<br />Measure<br />Results & Evaluation<br />Look at internal>external quality attributes (test internal metrics in-vivo and assess their predictive power)<br />
  45. 45. Modelling: The ‘Standard’ Endoscopy Report<br />
  46. 46. Development: GastrOS<br /><ul><li>.Net and C# ||| Thanks to Hong Yul!
  47. 47. openEhrV1 .Net C# Reference Model Library(from Ocean Informatics) + extended it
  48. 48. Standard MST Archetypes
  49. 49. Templates: for each endoscopy type
  50. 50. Introduced ‘GUI Directives’ for GUI generator
  51. 51. Wrapper + SDE Component= GST functionality</li></li></ul><li>GastrOS Templates<br />
  52. 52. GST vs. GastrOS<br />
  53. 53. Maintainability Assessment<br /><ul><li>Maintenance vs. maintainability
  54. 54. ISO/IEC 9216 and 25000 Software Quality std.
  55. 55. External QualityMaintainability characteristic
  56. 56. Changeability Subcharacteristic
  57. 57. Two metrics: (mainly look at maintenance tasks)
  58. 58. Change cycle efficiency (CCE)time from initial request to resolution of the problem
  59. 59. Modification complexity (MC)sum of time spent on each change per size of software change divided by total number of changes
  60. 60. 10 CR – real ones from GST usage
  61. 61. SVN + JIRA</li></li></ul><li>Preliminary Results<br />CCE 9 times less effort overall to modify GastrOS<br />MCthe changes were on average 7 times less complex<br />
  62. 62. Conclusion & Discussion<br /><ul><li>First ‘serious’ study to evaluate two similar but architecturally different applications
  63. 63. First ‘quantitative’ software maintainability evaluation in HI Literature
  64. 64. Extra look at ‘faults’ in addition to ‘effort’
  65. 65. Next look at non-domain related aspects (i.e. performance, availability, reliability etc.)
  66. 66. Challenge use GastrOS in other clinical domains and replicate results</li></li></ul><li>Thanks <br />Questions?<br />