How To Build A Health Care Information System (Hih)

Transcription

1 The Heterogeneous Healthcare Information Systems Integration: An Empirical Study based on SOA 研 究 生 : 楊 子 翔 指 導 教 授 : 孫 雅 麗 博 士 1

2 Outline Introduction Motivation and Purpose The HIS Problems and Visions The SOA Design and System Architecture The Scalability and Adaptability of SOA HIS: An Empirical Study The Distributed IIS Log Collector and Analyzer Performance Results Discussion Conclusion, Contribution and Future Works 2

3 Introduction Medical information systems were introduced into hospital three decades ago (Journal of medical systems, SCI, 1976) It helps physicians, nurses, and administrative staffs in their daily operations Healthcare information systems in a medical center Outpatient information system Inpatient information system Emergency information system Picture Archiving and Communication System/Radiology Information System(PACS/RIS) Laboratory Information System (LIS) Intensive Care Unit (ICU) - Clinical Information System(CIS) Ancillary systems 3

4 Introduction (cont d) Computer-based Physician Order Entries (CPOE) Provide a single integrated view of the patient-centered clinical record. Improve the quality of physicians and nurses clinical decisions The healthcare information system (HIS) is a collection of all information in the medical center It is difficult to use a single software application to support complex and varying requirements for patient care and treatment The interoperability and scalability for the HIS are important 4

5 Motivation Healthcare information system is complex (The Architecture of Enterprise Hospital Information System, 2005; Health information systems - past, present, future, 2006; Health informatics: current issues and challenges,2008;) A collection of information systems System, data, and workflow integration with healthcare IT solution providers The transition of HIS from departmental/ward-based to hospital based 5

6 Motivation (cont d) The requirements of Electronic Medical Records (EMR) (The Barriers to Electronic Medical Record Systems and How to Overcome Them, 1997; Factors and Forces Affecting EHR System Adoption: Report of a 2004 ACMI Discussion, 2004; Migrating to Integrated Electronic Medical Record: An Emprical Investigation of Physicians' Use Preference, 2009; EMR Adoption Model, 2010) Problems: can t find paper chart; can t read it; can t do the keyword search; no space for large paper charts; The EMR adoption rate is really low 6

7 Motivation (cont d) The HIMSS Analytics US EMR Adoption Model 7

8 Motivation (cont d) The important issues and challenges facing the healthcare information system in the historical hospitals and medical centers Transition, interoperability and scalability for both IT professionals and healthcare information employees. The complex HIS requirements (including EMR) have to be integrated into the workflow of the HIS in the medical centers To provide a uniform view to hospital employees 8

9 Purpose The proposed architecture must Have the scalabilities during the transition of the system, daily operations, system maintenance, and future requirements Can integrate healthcare IT solutions Adopt medical standard to achieve EMR requirements Fault tolerance and high system availability Introduce into medical center to prove it has the practical values High system performance 9

10 Outline Introduction Motivation and Purpose The HIS Problems and Visions The SOA Design and System Architecture The Scalability and Adaptability of SOA HIS: An Empirical Study The Distributed IIS Log Collector and Analyzer Performance Results Discussion Conclusion, Contribution and Future Works 10

11 The HIS Problems and Visions The revolution of HIS Problems and Visions The proposed SOA HIS 11

12 The revolution of HIS The first successful computerized medical information system El Camino Hospital (1971) Physicians, nurses, and administrative staff use the system as part of their daily activities. IBM 370 series mainframe computers with 1MB memory Using two 50k analog phone line to support Ralph K. Davies Medical Center Journal of medical systems (SCI, 1976) 12

13 The revolution of HIS (cont d) Johns Hopkins Hospital (1986) Using Ethernet to integrate inpatient, outpatient, emergency and ancillary systems Use a central and long-term database (LTDB) to share clinical data between systems Complex environment 13

14 Johns Hopkins hospital LTDB 14

15 The revolution of HIS (cont d) Client-server architecture Based on the Personal Computer (PC) and Ethernet network 15

16 The revolution of HIS (cont d) Web-based hospital information systems (2000) Use Web browser as the user interface to communicate with the Web server Embedded ActiveX components communicate to a SQL server through ODBC This is still based on the client-server architecture 16

17 Web-based HIS in 2000s 17

18 The revolution of HIS (cont d) summaries The architecture of HIS is based on the computer hardware and software. Mainframes Minicomputer with UNIX PC and Unix/with client-server and Web-based A long-standing medical center has systems of various architectures The main problem is how to integrate the different IT architectures and systems using a scalable new system architecture. Our motivation 18

19 Problems and Visions Problems (1) The transition and complexity of HIS requirements (2) The scalability of system performance, capacity and maintenance (3) The adoption of the EMR Visions 19

20 (1) The transition and complexity of HIS requirements HIS is a collection of information systems which supports the medical workflow and data integrations. The transition from departmental or wardbased systems to institutional/hospital-based systems According to this 2 issues, the HIS integration is hard to achieved. 20

21 (2) The scalability of system performance, capacity and maintenance The traditional systems have limitations: Mainframe, client-server, Web-based with single database repository No solutions can achieve user-unaware system maintenance or upgrade Centralized database architecture lacks the scalability for the future 21

22 (3) The adoption of the EMR The problems of the paper chart: Can t find the record, can t read it No space to store the paper chart Only 0.7% to reach the stage 7 of EMR in US,

23 Problems and Visions (cont d) Visions Propose a HIS architecture which can solve the problems described above Transition Integration Scalability EMR fulfill further requirements 23

24 The proposed SOA HIS According to the problems and visions we propose a scalable healthcare information system based on the health level seven (HL7) and service-oriented architecture (SOA) which called SOA HIS (1) Why SOA (2) Why Web Services (3) Why HL7 24

25 (1) Why SOA Service-oriented architecture A design style A way to define an IT infrastructure Regardless of the operating systems or programming languages A collection of services with stateless The healthcare requirements The heterogeneous healthcare IT solutions integration The SOA property: exchange data with Different applications, different operating systems, different programming languages (Service-Oriented Architecture," in Understanding SOA with Web services, 2005; Towards a Service- Oriented Architecture for Interconnecting Medical Devices and Applications, 2007) 25

26 (2) Why Web Services SOA need a collection of services with stateless Service can be implemented using RPC, DCOM, CORBA, Java RMI, Web services The Web services Can be written in C#, Java, Can be consumed on different platforms (OS) with different programming languages (Web Service-based Healthcare Information System (WSHIS): A Case Study for System Interoperability Concern in Healthcare Field, 2006; Towards a Service- Oriented Architecture for Interconnecting Medical Devices and Applications, 2007) 26

27 (3) Why HL7 (Health Level 7) An application layer protocol for healthcare The messaging based standards for exchange of clinical and administrative data among healthcare information systems The healthcare information system in medical centers Three main systems and ancillary systems must collaborate/integrate with each other 27

28 (3) Why HL7(cont d) HL7 is the standard used to be adopted into the SOA based healthcare information system HL7 is an application layer protocol Can be implemented as any kind of programming language and platform. According to the section Why Web Services, we implementation HL7 based on the Web services. The EMR: HL7 CDA (clinical document architecture) (Implementation of HL7 to client-server Hospital Information System (HIS) in the University of Tokyo Hospital, 1996; Interoperability of hospital information systems: a case study, 2003) 28

29 The HL7 SOA HIS Healthcare information systems have transition problems and have to integrate heterogeneous systems, the scalable requirements, adopt EMR. The SOA brings the integrating benefits of heterogeneous systems and system scalabilities The SOA needs Web services to realize The HL7 over Web services supports the SOA implementation and integration among the HIS and healthcare IT solutions which also eliminates the heterogeneous problems The HL7 has the benefits to adopting EMR based on the HL7 CDA. 29

30 Outline Introduction Motivation and Purpose The HIS Problems and Visions The SOA Design and System Architecture The Scalability and Adaptability of SOA HIS: An Empirical Study The Distributed IIS Log Collector and Analyzer Performance Results Discussion Conclusion, Contribution and Future Works 30

31 Service-Oriented Architecture (SOA) According to the problems of HIS, we choose SOA to design our new HIS. Service-oriented architecture A design style A way to define an IT infrastructure Regardless of the operating systems or programming languages A collection of services with stateless (Service-Oriented Architecture: Understanding SOA with Web services, 2005; A New Blueprint for I.T, 2005; Service oriented architecture (SOA) a new paradigm to implement dynamic e-business solutions, 2006) 31

32 SOA implementation Services SOAP, RPC, DCOM, CORBA, Java RMI Web Services Services language: Microsoft.NET CSharp, J2EE (Java), SOA service consumer and provider 32

33 The key technical characteristics defined for SOA HIS We define four key technical characteristics which can be used to solve the problems and achieve the visions of the HIS systems Services Interoperability Flexibility and scalability Fault tolerance 33

34 Services Considerations We planned to renovate each system at different time, so the service reusability was one of the key considerations Communicate with third-party systems, Java/C/C++/MS Visual Basic/.NET Framework Web Services provide a standard communication protocol, SOAP Can be used by any kind of programming language Almost all of the operation systems can provide the platform for SOAP 34

35 Interoperability The ability of two or more systems or components to exchange information and to use the information that has been exchanged There are many ancillary systems that have to integrate with each other to provide an integrated view Outpatient, inpatient, emergency systems Pharmacy system, nursing system, vital sign PACS/RIS, laboratory information system Must have the adaptability to extend into an EMR-ready system 35

36 Scalability and flexibility We do not know about the system scale in the future (requirements, application servers, database servers) We do not know about the computation power needed The scalability and flexibility during the healthcare transitions The IT department buys different brain servers and computational powers during the rightsizing steps The hardware and system upgrade, maintenance must be user-unaware with no service downtime 36

37 Fault tolerance Traditional mainframe and client-server architecture have less fault tolerance Not enough robustness for the mission-critical systems For the new SOA-based HIS, we have to provide a highly fault tolerant and distributed architecture for the medical system The services for the SOA HIS must provide high availability and the servers must be redundant to achieve high availability 37

38 The flexible architecture must fulfill these Provide for seamless system integration between the new and old systems The scalability of the database to provide access to multiple databases The hardware scalability and user-unaware maintenance for the SOA HIS system Provide high fault-tolerant services, and adding or removing services during the project 38

39 HL7Central: The Web servicesbased HL7 abstraction layer Starting from Service and Interoperability requirements Using Web services as our interface for the SOA HIS database Health Level Seven (HL7) Version 2.5, ANSI standard A message based application protocol with request-and-reply application model Implement using Web services 39

40 HL7Central: The Web services-based HL7 abstraction layer (cont d) HL7Central Based on Microsoft Internet Information Services (IIS) version 6.0 Service provider The data abstraction layer for the SOA HIS 40

41 HL7Central: The Web services-based HL7 abstraction layer (cont d) HL7 messages based on XML encoding over SOAP A Web services based on the SOAP WebUI sent HTTP POST POST /HL7Central_IIS/Central.asmx HTTP/1.1 Host: hiswsvc Content-Type: text/xml; charset=utf-8 Content-Length: length SOAPAction: " HL7Central reply HTTP/ OK Content-Type: text/xml; charset=utf-8 Content-Length: length <?xml version="1.0" encoding="utf-8"?> <soap:envelope xmlns:xsi=" xmlns:xsd=" xmlns:soap=" <soap:body> <HL7Port xmlns=" <HL7Input>string</HL7Input> </HL7Port> </soap:body> </soap:envelope> <?xml version="1.0" encoding="utf-8"?> <soap:envelope xmlns:xsi=" xmlns:xsd=" xmlns:soap=" <soap:body> <HL7PortResponse xmlns=" <HL7PortResult>string</HL7PortResult> </HL7PortResponse> </soap:body> </soap:envelope> 41

42 The service groups To achieve scalability and fault tolerance for the SOA HIS, we define the service groups and divide the servers into several service groups Services with layer 4 switch Load balance mode Active-standby mode 42

43 SOA HIS service groups 43

44 SOA HIS service groups (1) Portal service group The Web-based login page (2) Authentication and Authorization (AA) web service group Provide authentication and authorization to the portal service group Also for outpatient, inpatient and emergency WebUI service groups Provide Enterprise authentication for the third-party applications such as PACS A single-sign-on mechanism of the SOA HIS 44

45 SOA HIS service groups (cont d) (3) Authentication and Authorization (AA) Win service group A Windows service program Receives the AA Web service group real server requests and processes the authentication and authorization requests (4) WebUI service groups Provide the main CPOE interface to the physicians and nurses. 45

46 SOA HIS service groups (cont d) (5) HL7Central service groups Receive requests from WebUI real servers and relay the queries to the SOA HIS database The HL7 messages in the XML format (6) IIS State Server service group The session state is used to store an HTTP session between the user s browser and the Web servers. ASP.NET State Service (InProc, SQLServer, Custom, Off) 46

47 SOA HIS service groups (cont d) (7) Data Exchange Central Handles data exchange and data synchronization to the other systems WebUI, related ancillary systems, and third party systems do not need to know about the data integrity behind the HL7Central. 47

48 Data exchange and its procedures 48

49 Communication between service groups Portal AA Web Service AA Win Services Web UI HL7Central State Server Data-Ex. Central SOA HIS Database Portal AA Web Service AA Win Services Web UI Web Service X URL Redirect.NET Remoting Web Service HL7Central X X X StateServer X X X X Web Service (HL7MSG) ASP.NET Session- State X Data-Ex. Central X X X X TCP X SOA HIS Database X X Oracle Client X Oracle Client X Oracle Client 49

50 SOA HIS service groups 50

51 Service group name and virtual/real server settings Service Group Name FQDN of VIP Virtual IP Address Layer 4 Mode IP of Real Servers Portal Services Portal Load Balance/ Persistent Hash AAWeb Service WebAA Load Balance/ Least Connections AA Win Service WinAA Active-standby/ Persistent Hash Outpatient WebUI owebui Load Balance/ Persistent Hash , , Outpatient HL7Central ohl7centra Load Balance/ Least Connections , , Outpatient StateServer ostateserver Active-standby/ Persistent Hash Inpatient WebUI iwebui Load Balance/ Persistent Hash Inpatient HL7Central ihl7central Load Balance/ Least Connections Inpatient StateServer istateserver Active-standby/ Persistent Hash , , , ,

52 The sequence diagram of SOA HIS 52

53 Outline Introduction Motivation and Purpose The HIS Problems and Visions The SOA Design and System Architecture The Scalability and Adaptability of SOA HIS: An Empirical Study The Distributed IIS Log Collector and Analyzer Performance Results Discussion Conclusion, Contribution and Future Works 53

54 The scalability and adaptability of SOA HIS: An Empirical Study (1) The scalability and adaptability of the SOA HIS during the transition of NTUH rightsizing project (2) The scalability and adaptability of the service groups in the SOA HIS (3) The database scalability of the SOA HIS (4) The hardware scalability and adaptability of the SOA HIS 54

55 (1) The scalability and adaptability of the SOA HIS during the transition of NTUH rightsizing project Three main rightsizing steps: Outpatient, inpatient, emergency system First stage: outpatient rightsizing Outpatient: new SOA HIS system Inpatient: IBM mainframe with PCS and IMS/DB Emergency: HPUX with Sybase database, client-server application New patient registration from outpatient were also added to the inpatient and emergency system through the HL7Central and the Data Exchange Central processing 55

56 (1) The scalability and adaptability of the SOA HIS during the transition of NTUH rightsizing project (cont d) Second stage: inpatient rightsizing Inpatient system was integrated with the outpatient system using HL7Central to access the SOA HIS database and third-party databases. No data exchange requirements between inpatient and outpatient systems Data exchange process can be disabled in Data Exchange Central, so that WebUI and HL7Central developers do not need to recompile and redeploy their systems 56

57 (1) The scalability and adaptability of the SOA HIS during the transition of NTUH rightsizing project (cont d) Final stage: emergency system rightsizing Emergency system integrating into SOA HIS The code for data exchange was disabled in HL7Central Data Exchange Central no longer receives patient registration requests from HL7Central The WebUI developers still do not need to know about the complex data synchronization work behind the backend This kind of scalability for SOA HIS reduces development time and gives a method of assigning work to programmers 57

58 Scalability during rightsizing project 58

59 (2) The scalability and adaptability of the service groups in the SOA HIS 7 New outpatient service groups (January 2006) Portal service, AA web service, AA win service, outpatient WebUI, outpatient HL7Central, outpatient State Server, Data Exchange Central Add 2 inpatient service groups (February 2007) Inpatient WebUI, inpatient HL7Central 59

60 (2) The scalability and adaptability of the service groups in the SOA HIS (cont d) Add 2 emergency service groups (February 2009) Emergency WebUI, emergency HL7Central The procedure to adding service groups Install server hardware and Windows 2003,.NET, IIS 6 Define virtual IPs and fully qualified domain names (FQDN) for WebUI, HL7Central Define and assign real servers to the WebUI and HL7Central groups Configure layer 4 for the virtual IP, real server services, and the operation mode Deploy emergency software applications to the WebUI and HL7Central 60

61 Server components and layer 4 configurations Layer 4 Service SOA HIS Real servers Server Roles Enabled Mode L.B matrix Prod. Env. Test Env. Dev. Env. Portal V L.B P-Hash AA Web Service V L.B L-Conn AA Win Service V A.S P-Hash Outpatient Web UI HL7Central V V L.B L.B P-Hash L-Conn b 0 b StateServer V A.S P-Hash 2 1 a 0 b Web UI V L.B P-Hash b Inpatient HL7Central V L.B L-Conn b StateServer V A.S P-Hash 2 0 a 0 b Web UI V L.B P-Hash b HL7Central V L.B L-Conn b Emergency StateServer V A.S P-Hash 2 0 a 0 b Data Exchange Central V A.S P-Hash Oracle Database X Oracle L.B Oracle RAC Oracle RAC Database Solaris 9 Oracle RAC Database Solaris 9 Oracle Database Windows Abbreviations L.B: load balance A.S: Active-Standby P-Hash: Persistent Hash L-Conn.: Least Connections 0 b : use 1 b as the same server 0 a : use 1 a as the same server Prod. Env.: Production Environment Test Env.: Test Environment Dev. Env.: Development Environment 61

62 (3) The database scalability of the SOA HIS The SOA HIS has the ability to extend the databases based on the HL7Central service group The PACS/RIS A third-party system PACS has its own database which stores the patient images index and related information RIS has its own database which stores the radiology schedule and reports Physicians can see the PACS/RIS in the integrated view of the WebUI 62

63 (3) The database scalability of the SOA HIS (cont d) Access log database for the patient privacy After the second stage of inpatient rightsizing To log: which employers accessed which patient s records at what time MySQL database version built on FreeBSD 7.1 running on a PC server Dual Intel Xeon 1.6GHz Quad-Core with 4G memory About 60,000 records/6-month 63

64 (3) The database scalability of the SOA HIS (cont d) The Electronic Medical Record (EMR) of Department of Health (DOH) in Taiwan A public key infrastructure (PKI) based medical electronic certification mechanism Use another database schema stores electronic medical records Reuse HL7Central to construct the EMR information, fast developing 64

65 (3) The database scalability of the SOA HIS (cont d) 65

66 (4) The hardware scalability and adaptability of the SOA HIS Before the first stage: Sun Fire with 16 UltraSPARC-III+ processors IBM Blade Center HS21 with 2G Before the second stage: Extended 8 Sun UltraSPARC-IV processors IBM Blade Center HS21 extended to 3G The users were unaware of the upgrade activity Before the third stage: Bought new x86 based Dell blade servers prepare for our emergency system services This installation smoothly with no effect on our outpatient and inpatient services 66

67 Software architecture 67

68 Software architecture (cont d) 68

69 Hardware architecture 2 firewalls 2 layer 4 switches 2 layer 2 switches Oracle database with Real Application Cluster (RAC) Dual power for every server 69

70 Hardware architecture (cont d) 70

71 Outline Introduction Motivation and Purpose The HIS Problems and Visions The SOA Design and System Architecture The Scalability and Adaptability of SOA HIS: An Empirical Study The Distributed IIS Log Collector and Analyzer Performance Results Discussion Conclusion, Contribution and Future Works 71

72 The distributed IIS log collector Collect the IIS log for the outpatient, inpatient, emergency WebUI and HL7Central real servers For example: c:\ WINDOWS\system32\LogFiles\W3SVC1\exYYMMDD.log The real server compress the IIS log The log collector collects all the WebUI and HL7Central logs into the log server The outpatient, inpatient and emergency logs are put in the separated directories. 72

73 The distributed IIS log collector 1. for (each YYMMDD in Month) 2. { 3. for (each server_ip in Servers) 4. { 5. copy \\server-ip\path_to_iislog\exyymmdd.log.gz server_ip\ 6. } 7. } 73

74 The IIS log format 1 2 WebUI #Fields: date time s-ip cs-method cs-uri-stem cs-uri-query s-port cs-username c-ip cs(user-agent) sc-status sc-substatus sc-win32-status time-taken :00: POST /WebApplication/InPatient/Ward/NotifyOtherDoctor.aspx SESSION= B25482F8A25F322CBD689C Mozilla/4.0+(compatible;+MSIE+6.0;+Windows+NT+5.1;+SV1;+.NE T+CLR ;+.NET+CLR ) HL7Central #Fields: date time s-sitename s-ip cs-method cs-uri-stem 1 cs-uri-query s-port cs-username c-ip cs(user-agent) sc-status sc-substatus sc-win32-status time-taken :00:21 W3SVC POST /HL7Central_IIS/Central.asmx Mozilla/4.0+(compatible;+MSIE+6.0;+MS+Web+Services+Client+Protocol )

75 The distributed IIS log analyzer Implemented with Perl program and Perl module Statistics::Descriptive The WebUI service group regular expression filter qr'/webapplication/(\s*).aspx The HL7Central service group regular expression filter qr'/hl7central_iis/central.asmx'; Split one day into 24-hour slots Compute the average access time (time-taken) for each hour 75

76 Outline Introduction Motivation and Purpose The HIS Problems and Visions The SOA Design and System Architecture The Scalability and Adaptability of SOA HIS: An Empirical Study The Distributed IIS Log Collector and Analyzer Performance Results (Weekly, Monthly) Discussion Conclusion, Contribution and Future Works 76

77 Weekly performance Outpatient: about 9,000 patients/day Emergency: about 300 patients/day Inpatient: 2,200 inpatient beds in NTUH About 4,300 workstations involve our SOA HIS from our intra-network The WebUI processing time (response time) includes HL7Central and database processing time The HL7Central processing time shows the performance of the SOA based HIS 77

78 Weekly performance (cont d) One Week: 2009/05/25 ~ 2009/05/31 Aggregate within 1-hour Request counts Average response time Outpatient WebUI, HL7Central Inpatient WebUI, HL7Central Emergency WebUI, HL7Central 78

79 Weekly performance Outpatient WebUI Average: 0.79 seconds Heavy hours 0900~ ~1600 (0900~1600) 05/28 Dragon Boat Festival 79

80 Weekly performance Outpatient HL7Central Average (sec) Heavy hours Similar to WebUI Processing time HIS DB operations Third-party DB operation 80

81 Weekly performance Inpatient WebUI Average 1.25 (sec) Heavy hours 0800~

82 Weekly performance Inpatient HL7Central Average 0.04 (sec) Heavy hours Similar to WebUI 82

83 Weekly performance Emergency WebUI Average 0.82 (sec) Heavy load 0700 (Tue) 0300(Wed) 05/28 Dragon Boat Festival No affect 83

84 Weekly performance Emergency HL7Central Average (sec) Heavy load Similar to WebUI 05/28 Dragon Boat Festival No affect 84

85 Outpatient, inpatient, emergency WebUI and HL7Central The inpatient system is used twenty-four hours a day, and the utilizations is differently then the outpatient system Physicians and nurses check patient orders at night Nurses measure patient temperature, blood pressure, The emergency system is busy all the day until midnight including vacations 85

86 Outpatient, inpatient, emergency WebUI and HL7Central (cont d) Limitations The each request of IIS log can not provide system status in detail We do not discuss the reasons for the differing patterns of utilization between inpatient,outpatient, and emergency systems in detail We show that the response time of inpatient, outpatient and emergency service groups are acceptable for the different systems in the same SOA HIS architecture. 86

87 Monthly: Outpatient WebUI 87

88 Monthly: Outpatient WebUI (cont d) 88

89 Monthly: Outpatient HL7Central 89

90 Monthly: Outpatient HL7Central (cont d) 90

91 Monthly: Inpatient WebUI 91

92 Monthly: Inpatient WebUI (cont d) 92

93 Monthly: Inpatient HL7Central 93

94 Monthly: Inpatient HL7Central (cont d) 94

95 Monthly: Emergency WebUI 95

96 Monthly: Emergency WebUI (cont d) 96

97 Monthly: Emergency HL7Central 97

98 Monthly: Emergency HL7Central (cont d) 98

99 Outline Introduction Motivation and Purpose The HIS Problems and Visions The SOA Design and System Architecture The Scalability and Adaptability of SOA HIS: An Empirical Study The Distributed IIS Log Collector and Analyzer Performance Results Discussion Conclusion, Contribution and Future Works 99

100 Discussion System performance discussion The scalabilities in the future (1) the authorization granularity (2) the digital signature for EMR (3) The UDDI, WSDL, and Web Service Standards 100

101 Discussion - Monthly statistics The WebUI and HL7Central response time distributions are different HL7Central: almost 100% requests had finished within 0.5 seconds WebUI: Outpatient: 50%, 0.5 seconds; 20%, 1.0 seconds Clear variation then inpatient Inpatient: 50%, 0.5 seconds; 20%, 1.0 seconds Stable variation then outpatient Emergency: 35%, 0.5 seconds; 40%, 1.0 seconds Stable variation then outpatient 101

102 Discussion - Monthly statistics(cont d) The difference in the outpatient, inpatient, and emergency WebUI response time distributions The difference in the system usages The different of the WebUI programming style Different complicating WebUI business logic There could be many reasons to discuss the differences and, currently, the reasons are beyond this research. 102

103 The scalabilities in the future (1) the authorization granularity The authorization Healthcare system users System functionalities The extended authorization Healthcare system users System functionalities Patients Modified the AA related service groups and WebUI AA services call The nursing scheduling and resident doctor assignment system must support 103

104 The scalabilities in the future (2) the digital signature for EMR The HL7 CDA EMR is generated by re-using the HL7 messages through HL7Central The digital signature for EMR by using Smart Card(HCA card) Background processing after medical users finish one case Batch processing before off duty Both background or batch processing can be done by re-using HL7Central to construct HL7 CDA for EMR The digital signature program can be implemented Web-based or client-server which reuse HL7Central and integrated into CPOE (or standalone program) 104

105 The scalabilities in the future (3) The UDDI, WSDL, and Web Service Standards Currently, the SOA HIS does not consider about the UDDI and WSDL for public usage The HL7 based application protocol over Web services does not have standard WSDL for each HL7 messages at year 2004 In the future, there can be implemented an HL7 public gateway which supports the HL7 WSDL standard and publishes UDDI for public usage The HL7 public gateway also utilizes the HL7Central 105

106 Outline Introduction Motivation and Purpose The HIS Problems and Visions The SOA Design and System Architecture The Scalability and Adaptability of SOA HIS: An Empirical Study The Distributed IIS Log Collector and Analyzer Performance Results Discussion Conclusion, Contribution and Future Works 106

107 Conclusion In this thesis we review the traditional HIS drawbacks and define the new system requirements for our new HIS system We proposed, designed and implemented a SOAbased HIS which has great scalability in most situations. We described a successful rightsizing project from IBM mainframe to a multi-tier architecture for the proposed SOA HIS in NTUH 107

108 Conclusion (cont d) The SOA HIS Services, interoperability, scalability, fault tolerance Contains several service groups and provides a scalable, fault tolerance system architecture The NTUH SOA HIS shows the scalability during the rightsizing project service groups databases System and hardwares 108

109 Conclusion (cont d) The NTUH SOA HIS performance results Reasonable response times under the different outpatient, inpatient, and emergency systems The WebUI of the three systems show the different utilizations The HL7Central of the three systems indicate great performance results The SOA is sustainable in a highly demanding healthcare environment The SOA-based architecture can be adopted into any mission critical information systems for the enterprise. 109

110 Contribution The main contribution of this dissertation is that we propose, design, and implement the HL7 based SOA HIS which has the ability to handle the transition in healthcare information system, integrate the healthcare IT solutions, and adopting electronic medical records for the complex healthcare requirements in medical center. The first HL7 based SOA HIS design in year 2004, and the most complete HL7 SOA HIS implemented 110

111 Future works Finding and resolving the system bottleneck WebUI Analyze the detailed IIS log to collect the response times that over N seconds Analyze the results of the slow records to see if there are the same slow WebUI pages Find out the problem and refine the source codes The user behaviors HL7Central Monitoring the HL7Central performance results If there are fewer then 90% of response time below 0.5 seconds Find out the problem with the HL7Central of database performance issues 111

112 Future works (cont d) Extend the services and SOA HIS into cloud computing Extend the HL7Central into cloud computing Patient demographics, registration services, diagnosis services, prescription services, radiology services, laboratory services These services are provided by healthcare datacenters and can be used by any level of hospital in Taiwan The patients have their own medical records in the datacenter and the records can be retrieved from the authorized hospitals This could be a good path toward adopting EMR for the nation 112

113 Suggestions and comments 113