The document discusses the challenges and complexities of software maintenance and maintainability in healthcare, particularly focusing on health information systems and the associated difficulties in meeting changing requirements. It highlights the significant costs and risks involved in healthcare IT projects, as well as the implications of using the openEHR architecture in developing more sustainable software solutions. The author presents a case study comparing two applications to assess maintenance metrics, suggesting that the new architecture can lead to reduced effort and complexity in modifications.

1. Why IT Fails in Healthcare? A look at Software Maintenanceand Maintainability AspectsKoray Atalag, MD, PhD23 Mar 2010

2. AgendaA look at Health ITEssential difficulties and implicationsHealth Informatics – directionsMaintenance burden in HISopenEHR ParadigmMy research frameworkDevelopment workMeasurement & EvaluationResultsDiscussion & Conclusion

3. Healthcare – Burning IssuesCost increasing rapidly16% GDP in US, ~8-9 in EU & NZ (Ref: OECD)Quality ? (far from measuring effectively)Safety (you don’t wanna know):appx 90,000 people die each year in US due to preventable medical errors! (Ref: Institute of Medicine)Equity / Accessibilitybig differences related with geography, political, socio-economic status

4. Health IT – What is it all about?Health Information Systems (HIS): ProviderGP systems, Hospital Information Systems, LIS, RIS, CIS, etc. etc.Regional/National PHO, DHB, NHI, ACC etc.Consumer orientedPHR: Microsoft HealthVault, Google Health, other. Patient portals: Mayoclinic.com, The LowDown.co.nz Research related Genome DB, Medline, Health Computational Systems: CT, MRI, ECG etc.Health Communication Systems: HealthLink, NPI, DICOM

5. Essential DifficultiesBreadth and Depth of Medical DomainA medical student learns about 6000 new concepts (and sleeps much less than others!)>600,000 concepts, 1.2m relationships in SNOMEDComplexity of concepts and processesGene>Structure>Function? + Environment+LuckVariability in Medical PracticeMedical conduct changes acc. to time/person and across different organisations and jurisdictions

6. Health InformaticsMedical Informatics Nursing informaticsBioinformaticsBiomedical InformaticsHEALTH INFORMATICS:“ Health Informatics is the science and practice around information in health that leads to informed and assisted healthcare.”HISO – Australia$mostly public funding & secondary care (hospitals)$20b stimulus package for health IT in US£70b NHS CfH and Canada Health Infoway Project

7. Tackling These Difficulties?Standardised terminologyMachine processable biomedical ontologyClinical guidelines & Decision SupportFunctional and Technical Standards: HL7, CEN/ISO, IEEE, ASTM, OMG – mostly openOpen Source tools and librariesEHR ArchitecturesTools and methodologies to effectively use IT in healthcare: mHealth, VR, telehealth, robotics

8. Implications on Health ITLow market penetration (AVIS/ Visa/Foodtown)Increased cost: many projects either fail or over budget/scheduleDecreased satisfactionDelivering on expectations? Improving healthcare?*** Maintenance & Interoperability major issues

9. Maintenance of HISConstitutes the majority of development costs

10. Degrades overall quality / longevity / satisfactionSource of problem change in domain related requirements (mostly fxnal)How?Incomplete / wrong req. at outset

11. New / no longer valid requirementsWhy?Essential + handover

12. Volatility of domain concepts & processesAn Important “bottleneck”Cognitive friction /limits to human communication Unknown requirements

13. Wrong requirementsChanging requirements?“handover”

14. The “handover”...Isn’t this the reality in health IT?So far so good...Not only the body of knowledge can only partially be “handed” over, but also it might just be “too much to handle”: Techiesnature of Biomedical sciences

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" syndromeMy Past ExperienceDeveloping HIS since 1995

16. Own company, employee, academician, freelance consultant and contractor

17. Main problem=maintenance

18. Case study: Endoscopy Reporting Application

19. Started 1999 as commercial project

20. Went well initially but then….

21. Became academic and served as PhD prototype

22. I have collated all CR over its usage

23. Motivation for my thesis and researchResearch PrototypeGSTAutomatic report generation

24. openEHR Formalism Complete set of engineering specifications for EHR Architecture and HIS development Open Access – not for profit Foundation Adopted by ISO & CEN (13606)Separate tasks of developers & domain experts

25. Separate domain knowledge from software code DSL + MDA essentially; differences:A reference model (RM)

26. Models structure RM Classes and puts constraints on runtime Objects

27. openEHR FoundationNon-profit organisation based at University College, London (UCL)

28. Established by UCL and Ocean Informatics in 2000 to own the IP

29. 800+ Members from 71 countries

30. All specifications & schemas publicly available

31. Software open source (GPL, LGPL, MPL)Key Innovations“Multi-level Modelling” – separation of software model into distinct layers:1) Technical information model (generic)2) Concept models: Archetypes (domain-specific)3) Terminology/Ontology (SNOMED etc.)Software code is based on only the first layer

32. Minimal ‘handover’

33. Driven by Archetypes in run-time

34. High level semantics delegated to terminologyMulti-Level Modelling

35. openEHR PlatformQueriesHealth Integration PlatformArchetypesHealth Information PlatformEQLTOMApplication Development PlatformKnowledge Management PlatformAOMADLTemplatesReference Model

36. How it works?

37. Current openEHR Specifications

38. Anatomy of DV_TEXT Data Type

39. Domain Specific Aspects of RM

40. EHRFoldersCompositionsSectionsEntriesClustersElementsData valuesLogical building blocks of EHR

41. Archetypes?Constraints on an information modelStructural constraintsList, table, treeWhat labels can be usedWhat data types can be usedWhat values are allowed for these data typesHow many times a data item can exist?Whether a particular data item is mandatoryWhether a selection is involved from a number of items/valuesUsed by systems to control creation and validation of data, and to perform queryingArchetypes: a clinical model

42. Anatomy of an Archetype

43. Archetype Definition Language (ADL)OCL+DDL

44. My Research FrameworkModelling of Endoscopy DomainStage-1:SRS based on previous app (GST)Develop openEHR based GastrOSStage-2:Select CR from past usage of GST Implement in GastrOS + check (repeat for some) in GSTDetermine metrics & measureStage-3:New CRImplement changes in both applicationsMeasureResults & EvaluationLook at internal>external quality attributes (test internal metrics in-vivo and assess their predictive power)

45. Modelling: The ‘Standard’ Endoscopy Report

46. Development: GastrOS.Net and C# ||| Thanks to Hong Yul!

47. openEhrV1 .Net C# Reference Model Library(from Ocean Informatics) + extended it

48. Standard MST Archetypes

49. Templates: for each endoscopy type

50. Introduced ‘GUI Directives’ for GUI generator

51. Wrapper + SDE Component= GST functionalityGastrOS Templates

52. GST vs. GastrOS

53. Maintainability AssessmentMaintenance vs. maintainability

54. ISO/IEC 9216 and 25000 Software Quality std.

55. External QualityMaintainability characteristic

56. Changeability Subcharacteristic

57. Two metrics: (mainly look at maintenance tasks)

58. Change cycle efficiency (CCE)time from initial request to resolution of the problem

59. Modification complexity (MC)sum of time spent on each change per size of software change divided by total number of changes

60. 10 CR – real ones from GST usage

61. SVN + JIRAPreliminary ResultsCCE 9 times less effort overall to modify GastrOSMCthe changes were on average 7 times less complex

62. Conclusion & DiscussionFirst ‘serious’ study to evaluate two similar but architecturally different applications

63. First ‘quantitative’ software maintainability evaluation in HI Literature

64. Extra look at ‘faults’ in addition to ‘effort’

65. Next look at non-domain related aspects (i.e. performance, availability, reliability etc.)

66. Challenge use GastrOS in other clinical domains and replicate resultsThanks Questions?