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

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide

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: Mayoclinic.com, The LowDown.co.nz <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 />