Anwendungen im Gesundheitswesen

Transcription

1 Anwendungen im Gesundheitswesen Einführung Vorlesung mit Übung WS Dr. Barbara Tappeiner Dr. Wolfgang Schramm Prof. Geraldine Fitzpatrick Prof. Thomas Grechenig INSO - Industrial Software Institut für Rechnergestützte Automation Fakultät für Informatik Technische Universität Wien

2 Organisatorisches Vorlesung Mo. 16:30-18:30 st, EI5, Seminarraum Argentinierstr. Sprache Deutsch und Englisch Vorbesprechung Vorlesungsteil ab Keine Anwesenheitspflicht Anwesenheit jedoch sehr empfohlen! Achtung: Spezielle Einheit zur Übung am Anwesenheit bei dieser Einheit absolut erforderlich!

3 Introduction 3

4 Important Concepts E-Health Educational Games M-Health Social Platforms Health 2.0 Personalized Healthcare

5 e-health: electronic Health General term for various concepts: Telemedicine Electronic health record (EHR) Interactive/participative health care Information systems in health care General: Electronic processing and exchange of health data and/or medical knowledge.

6 m-health: mobile Health Supporting Health Care with mobile technologies (e.g. Hotlines, SMS-Applications, Apps on Smart Phones). Applications for: Health Care Professionals: e.g. Consultations, Patient Monitoring, Literature, Medical Algorithms Patients: Collecting personal parameters (e.g. fitness, medical information, ), contacting health care professionals Surprise: Demand also in Low Income and emerging countries not only in developed countries. Why? Health is no luxury good!

7 mhealth Example Application Topics Education and awareness Helpline Diagnostic and treatment support Communication and training for healthcare workers Disease and epidemic outbreak tracking Remote monitoring Remote data collection 7

8 App Examples (Quelle: Android Market) 8

9 mhealth Stakeholders in Development/Operation 9

10 m-health: mobile Health cont. Konkrete Ziele die im Zusammenhang mit m-health oft genannt werden: Prävention Verhaltensänderung (Behavior Change Communication) Durch die aktive Einbeziehung des Patienten in seine Gesundheitsdokumentation und der daraus folgenden Bewusstseinsmachung soll es zu AKTIVEN Verhaltensänderungen seitens des Patienten kommen. Sehr stark von Interesse in der chronischen Behandlung von Übergewicht, kardiovaskulären Erkrankungen und Diabetis.

11 Health 2.0 Comparable to Web 2.0 Content is not exclusively produced by few Creators (Health Care Providers). Content is also created by the general population (Patients): e.g. in form of Therapy diaries Participative Health Care. Closely related to Personalized Healthcare, e-health and m- Health. Web 2.0 possibilites: wiki, blog, tagging, social platforms, groups Information, Data and Experience Transfer & Exchange Networking, Grouping Security & Privacy Issues and Awareness

12 Educational Games Goal: Visualization of complex processes by simulating Real- Life events. From Microcosm Physiological Simulations System Biology Chemistry Education Software To Macrocosm Games for environmental protection training Presenting global events.

13 Personalized Healthcare Therapy Diary Individual Healthcare by using genomic information Continous Record keeping Goal: Individualizing healthcare to provide high quality care.

14 Social Platforms Exchanging Information between: HCP Patients Patients Patients HCP HCP Easy communication facilitates effective communication workflows. Security, Privacy Issues and Awareness

15 Integrating Doctors: Sceptical User Group That it will ever come into general use, notwithstanding its value, is extremely doubtful because its beneficial application requires much time and gives a good bit of trouble, both to the patient and to the practitioner because its hue and character are foreign and opposed to all our habits and associations The London Times, 1834

16 Integrating Doctors: Sceptical User Group What was this quote all about: The Stethoscope!

17 Design Criteria and Stakeholders for Applications in Health Care 17

18 E-Health Project Any sufficiently large IT infrastructure project on a regional, national or international level can be cognitively described along four major abstraction levels: 1. Political/Public Level Political/Public Criteria (PC) 2. Institutional Level Institutional Criteria (IC) 3. Operative/Process Level Operational Criteria (OC) 4. Technical Level Technical Criteria (TC) A project can only be successful by dealing with all four levels! 18

19 Applications in Healthcare Examples / Brainstorming Level Nationwide electronic health record system Hospital Information system Mobile Home Care Record System Netdoktor.at Fitness-App on Smartphone Political Parliament, Citizens Health Ministry for Budgeting Health Ministry, Gov.Institutions for Budgeting Citizens? Citizens? Institutional Ärztekammer, Hauptverband der SVT, Hospitals, Doctors, Farmacies, Hospital, Hospital Staff Ärztekammer, Hauptverband der SVT, Hospitals, Doctors, Farmacies, Platform Owner Depending on Integration. HCPs, Hosptitals Operational Institution/ Company for operation Hospital IT Department Home Care Providers Content Management App Providers Technical Implementer, Operator Hospital IT Department Implementer, Operator Technical Development, Implementer Developers 19

20 Political Level Consideration of cultural aspects and historical development in healthcare Appropriate and necessary innovation Healthy Growing: Creating a healthy ehealth Infrastructure Step-by- Step Appropriate design of media presentation, dealing with fears and enhancing Acceptance Appropriate allocation at the general governmental level Representation in parliament and other representative organisations for citizens Appropriate legislative measures to accompany the implementation process and operation of the system 20

21 Expectations on Applications in Healthcare 21

22 Consideration of cultural aspects and historical development in healthcare Gently introduce new applications. Always take existing systems and developments into accounts. Always start by showing potential benefits for all main stakeholders: Health Care Professionals Patients Government 22

23 Appropriate and necessary innovation Core Innovations Electronic Medical Record Emergency Record Medication Interaction Everything else makes sense only after those core components. New technologies 23

24 Healthy Growing: Creating a healthy ehealth Infrastructure Step-by-Step Two Approaches: Design a fully featured Health Infrastructure While good on paper it is nearly impossible to implement Start with a small core Extensible architecture Small projects make success possible 24

25 Appropriate design of media presentation, dealing with fears and enhancing Acceptance Shaping public opinion is essential for success Health is an emotional topic There will be many discussions about Pros / Cons Fears have to be taken seriously 25

26 Appropriate allocation at the general governmental level Healthcare projects are long-term projects > 5 years. Governmental changes always pose a risk to the project! Promoters Deciders 26

27 Representation in parliament and other representative organisations for citizens Every project has to take in account and deal with political processes. 27

28 Appropriate legislative measures to accompany the implementation process and operation of the system For a successful project a compliant legal framework is essential. Without legal framework a project is likely to fail even after technical completion. 28

29 Institutional Level System and Application Acceptance for Primary and secondary healthcare centers for Health Insurances for Hospitals for Pharmacies for Nursing and Nursing homes for Patients 29

30 Institutions Identify Institutions: Which institutions are involved and what agenda or goal do they have? Describing benefit: What is the benefit for the system for the institutions? Solution process: The goals of every institution should be discussed with them. The requirements of the solution finding process should be taken into consideration by the political level. System acceptance: among the institutions there are different stages of acceptance. Some of them will like the system and some will not like it at all. You have to determine why acceptance among some groups is low and try to increase it. 30

31 System Acceptance for Primary and secondary healthcare centers Generally entry point into health system. Doctors from the primary and secondary healthcare sector are usually strongly represented in large health care IT projects. Usually a group associated with skepticism against new technology preserver of the status-quo. Critical that improvements are presented early in the project. 31

32 System Acceptance for Health Insurances Usually very interested or even project driver. Primary Goal: reduce costs IT can help in this regard. In competition situations Vorsprung durch Technik, advantages with innovative applications for insured citizens 32

33 System Acceptance for Hospitals Usually have their own autonomous systems. Involvement of clinics should be clearly defined. Any project involving Hospitals (especially large ones) has to actively handle their specific requirements. Data Storage Interoperability / Data Integration 33

34 System Acceptance for Pharmacies Main partner for projects involving medication interaction checks. Process improvement, Catalogues Prescription handling Medication checks ehealth Systems could enable new business cases for pharmacies (e.g. Medical consultant) 34

35 System Acceptance for Nursing and Nursing homes Increased life expectancy drives innovation for home and selfcare. Ideal setting for centralized health-record / longterm record keeping. Mobile Data Collection Many projects dealing with 24/7 Monitoring Ambient Assisted Living. 35

36 System Acceptance for Patients Potential for an higher amount of patient interaction. Patient as owner of his/her data Legal requirements Process design (eg. patient consent, data handling, substitute) Risk of data abuse is critical for patients. Security Privacy Trust in Data Store 36

37 Operational / Process / Project Planning Level Effective Project Management Planning rollout scenarios (who will install what, when, and where) Adaptability and framework quality, change management Locality of medical or e-health services Accessibility and Ownership of patient or treatment data Maintainability Integratability and interoperability of heterogeneous systems Transparency of data transmission and audits 37

38 Adaptability and framework quality No large-scale Health-IT Project is or will be static. Constant change is nothing to be afraid of in a well designed system. Operational level has to continue work even when institutional and/or political change. 38

39 Locality of medical or e-health services Determine who the endusers will be. How will the services be accessible (e.g. VPN) This directly translates into access and security requirements for the services. 39

40 Accessibility and Ownership of patient or treatment data Who will be able to access what information how? Who will have data-ownership and responsibility? Required availability results from these basic questions. 40

41 Maintainability Maintenance complexity rises with the system complexity. Maintenance, Releases Support: Call Center, Trouble Ticketing Tools Keep maintainability as simple as possible. Defined maintenance cycles and announced downtimes are required to preserve the image of a well running system. 41

42 Integratability and interoperability of heterogeneous systems Every Health IT services has to be integrated into some other system at some point. Interfaces should provide a clear, simple and secure access. Usage of established IT standards (eg. HL7, DICOM,..) is essential. 42

43 Transparency of data transmission and audits At any point it should be reproducible who accessed what data but not the data itself. Clear access and administration roles have to be defined. 43

44 Technological Level Security Usability Scalability Reliability 44

45 Security Prevention of misuse, unauthorized access manipulation and destruction of data; local data risks Depending on the planned services, different security mechanisms and strategies have to be implemented. Frontend, Backend and communication have to be appropriately secured. Distinguish between: Onsite Security Communication Security Application Security 45

46 Usability Engineering Easily usable for patients, physicians, pharmacies Enduser have to be involved from the beginning Repeated User Acceptance tests help to identify potential problems early on. Large Health IT systems deal with a highly diverse target population. 46

47 Scalability scalability of components and traffic as well as the ease of integration of new applications into the e-health telematic system Vertical Scalability New services Integration into other systems Horizontal Scalability Include larger target audience. More simultaneous requests on the system. 47

48 Reliability robust in medical environments; stable and accessible 24h and 7 days a week; off-line and remote scenarios supported Typical failure scenarios: Failure of the underlying hardware (e.g. switches, servers, data storage components) Failure of the housing infrastructure (flooding, power, air condition etc.). Broken physical connections (e.g. cabling) Very high latency (i.e. longer than network timeouts) due to excessive arbitrary usage of the network by other users Contingency plans for these scenarios are essential to provide a reliable system. 48

49 Stakeholder Alignment 49

50 Iterative Design Process 50

51 Natural Order of Criteria Levels PC>IC>OC>TC 51