HIE. Introduction. A standards-based distributed Healthcare Integration Engine. Abstract. Interoperability between heterogeneous systems is

Transcription

1 HIE A standards-based distributed Healthcare Integratin Engine Institut Superir Técnic Ricard Miguel Simões Seir ricard.seir@tagus.ist.utl.pt Abstract The main gal f this wrk is t prpse a new integratin system named HIE that is designed t satisfy the specific needs f the healthcare market. This system shuld allw the establishment f cmmunicatin channels between hetergeneus healthcare systems. T achieve this gal, the system must supprt the mst used interperability standards in this dmain like HL7 r DICOM, alng with ther general-purpse nes like XML, Web Services r Databases. The system shuld be extensible t supprt the future additin f ther standards and it shuld als be cnfigurable thrugh an accessible interface that desn t require a deep knwledge f the used standards. Intrductin Interperability between hetergeneus systems is ne f the ldest issues in IT and is still cnsidered a prblem tday. Many rganizatins can benefit frm the sharing f infrmatin between its systems, with better accessibility t their data and mre agility in their business prcesses. In the healthcare dmain, cmmunicatin between infrmatin systems imprves the quality f the prvided health services, reducing the need fr manual (re)intrductin f data and imprving the quality f medical decisins with better access t vital infrmatin. [1] In the last decades there were significant breakthrughs with the creatin f general-purpse interperability standards like EDI r XML and dmain-specific nes like HL7 r DICOM [2], fr healthcare. These standards have made it easy t create pint-t-pint interfaces between infrmatin systems. Hwever, the expnential grwth [3] f these types f interfaces has raised sme prblems t the rganizatins, mstly related t their maintenance. The purpse f this article is t prvide a high level verview f the key cncepts used in the system, withut ging int implementatin details. This system is being develped at the sftware cmpany Infrtucan, specialized in healthcare sftware slutins. Keywrds: interperability, standards, integratin engine, HL7, DICOM, XML In rder t avid these issues, rganizatins started turning twards integratin middleware, cmmnly knwn as integratin engines. This type f sftware is specialized in the creatin f interfaces using different cmmunicatin standards, prviding tls t manage them centrally. Integratin engines have been gradually replacing pint-t-pint interfaces, althugh these are still very cmmn tday. In the healthcare dmain there are still many flaws in this type f prducts, frm the absence f

2 supprt fr sme f the mst used standards, t the lack f flexibility prvided fr cnfiguring interfaces and even sme perfrmance and scalability issues. Architecture Service Cntainers where different integratin services are deplyed, prvided with internal endpints t exchange messages with ther services r the parent cntainer thrugh the message bus. The architecture f the HIE system is based n the fllwing set f architectural patterns and principles: Enterprise Service Bus & SOA Layers Mdular Design Enterprise Service Bus & SOA One f the main cncepts behind the architecture f the system is the Enterprise Service Bus, an architectural pattern prpsed by Dave Chappell. [4] Enterprise Service Bus Architectures based n this pattern allw the service cntainers t be deplyed in different machines, prviding a distributed system. The ESB pattern is intimately related t SOA (Service-Oriented Architecture) principles. With an ESB we can create different instances f reusable integratin services and then cmbine them t frm f service rchestratins. An rchestratin can then be made available fr ther systems by defining an external endpint (like a Web Service) and linking it t the rchestratin. WS XSLT ODBC Internal Endpint Integratin Service Service Cntainer Layers Anther architectural pattern used in the cnceptin f the system is the layers pattern [5], where the External Endpint system is structured accrding t different layers f functinality that depend n the layers belw. The layers defined fr this system are the fllwing: Figure 1 - ESB Architectural Pattern Users Service Cnsumers The main features f an ESB are the fllwing: Presentatin (Client) Presentatin (Server) Services Message Bus that can be prvided by a regular MOM (Message-Oriented Middleware); Integratin Services that can prvide external Cnfiguratin Mnitring Security Persistence Business Lgic Messaging Cmmunicatin endpints fr ther systems t cnnect t, like DBMS MOM External Systems Web Services r HL7 interfaces r ther utility services like Transfrmatins r CBR (Cntent- Based Ruting); Figure 2 - Layers f the HIE system

3 Presentatin respnsible fr the interface that Mnitring a set f rules that defines hw t allws the user t cnfigure the different parts mnitr the different cmpnents f the system f the system. This layer is subdivided int thrugh fur different levels f event lgging: client-side and server-side cmpnents. The client-side cmpnents are required fr cmplex user interactins like visual mapping between message schemas. Service Cntainer Event Lgs; Integratin Service Event Lgs; User Activity Event Lgs; Message Lgs; Services this layer prvides the external Cnfiguratin a set f principles that define endpints used by external systems t cnnect which parts f the system shuld be t this system; cnfigurable and which nes shuldn t. Business Lgic cntains the cre classes f the system like dmain bjects and utility classes; Persistence used fr strage and recvery f data using a database; Messaging prvides lw level functins used Mdular design The last architectural pattern that is used by the HIE system cnsists f the separatin f its parts int different cmpnents that can be develped independently. t cmmunicate with the MOM fr sending and receiving messages; Cmmunicatin prvides the lwer level mechanisms required fr establishing cnnectins with external systems using different cmmunicatin prtcls (like DICOM r HL7); This mdel als cntains three different znes that represent imprtant system-wide plicies: The cmpnents f the system are the fllwing: Service Cntainer respnsible fr hsting integratin services, creating a different thread fr each ne. The cntainer is als respnsible fr managing the life cycle f its services; Base Service generic base frm which every integratin service inherits parts f its features, allwing them t fcus nly n prviding their business value; Security security-related plicies that try t prtect the system frm a six categries f threats defined by the STRIDE acrnym [6]: Spfing; Tampering; Repudiatin; Infrmatin Disclsure; Dmain Classes infrmatinal entities managed by the system; Supprt Classes DAO classes, helper classes and ther utilities; HL7 Utilities HL7 supprt classes that allw us t parse, encde, send and receive HL7 messages; Denial f Service; Elevatin f privilege.

4 DICOM Utilites DICOM supprt classes that allw us t parse, encde, send and receive DICOM messages; XML Utilities XML utilities that allws us t parse, encde, query, (XPath) transfrm (XSLT) and validate (XSD) XML dcuments; based n XML and must reference the XSD schema used t validate its cntents. This ensures that nly valid messages flw thrugh the bus, allwing them t be ruted and transfrmed by internal services. On the ther hand, this means that every service that receives input frm an utside surce must Cmmunicatin Classes classes that implement lwer level prtcls like TCP/IP; cnvert that infrmatin t XML befre sending it t anther service, which means that autmatic Persistence Classes classes that implement lwer level cmmunicatin with a DBMS (DataBase Management System); Messaging Classes classes that implement lwer level cmmunicatin with the MOM that cnverters shuld be used fr messages that use ther encdings. There are tw types f interactins between services: implements the message bus; Request-nly a message is sent and the Integratin Services classes that implement service resumes its previus state; the abstract methds f the Base Service, prviding new business value fr the system; Request-respnse a message is sent and the service blcks, waiting fr a respnse message Web Interface presentatin-related classes that prvide the user interface. in its message queue. The request-respnse pattern is required fr synchrnus peratins like Web Service interactins that need t send Implemented Integratin Services The HIE is mainly cmpsed f service cntainers and integratin services that are hsted by the cntainers. There are tw kinds f services: a respnse t the requester and that respnse is generated in anther service; In the current prttype there are ten different service types that represent the building blcks f Interface services these prvide external endpints used by ther systems t access the HIE; Internal services these prvide sme utilities like message ruting r transfrmatin that are key elements in an rchestratin; the rchestratins. These services will nw be described: Transfrmatin takes an input XML, transfrms it int anther XML dcument and validates the result befre sending it t anther service; Every service has an internal endpint available t exchange messages with ther services deplyed in the system. The cntents f the messages are always Cntent-Based Ruting frwards a message t anther service based n its cntents, which is verified with XPath expressins;

5 HL7 Receiver receives HL7 messages and cnverts them t XML if their schema is recgnized. This service can be cnfigured t implement request-respnse interactins; HL7 Transmitter sends an HL7 message t ne r mre external systems and can wait fr a respnse, if cnfigured accrdingly; DICOM Wrklist SCP this service implements a DICOM Wrklist SCP (Service Class Prvider), allwing imaging mdalities t query it fr Web Interface The Web interface allws authrized users t cnfigure all the aspects f the system, review the lgs and message queues and mnitr the status f the integratin services. The interface is divided int several cmpnents that are independent and require different access permissins frm the users registered in the system. The cmpnents f the interface are: scheduled prcedures steps; DICOM MPPS SCP implements a Mdality Perfrmed Prcedure Step SCP that can receive data related t exams perfrmed by imaging mdalities. The received infrmatin can be cnverted t XML and sent t ther services; DICOM Query/Retrive SCU this service can query remte Strage SCPs fr images r ther DICOM bjects and ask these systems t send these bjects; Database this service can send SQL cmmands t databases. When cnfigured t send queries, the system receives the data and cnverts it t the XML frmat fllwing the schema f the data table frm where the results are retrieved; Web Service this service is cnfigured t receive SOAP requests frm ther systems, making its WSDL cntract available s that thers can build client stubs frm it in rder t use the service; Web Service Caller this service sends SOAP requests t external web services. The remte web service schema is extracted previusly and used t cnfigure the service autmatically. Orquestratin management allws users t create, delete and mdify rchestratins (by adding r remving service instances); Service Cnfiguratin this cmpnent allws a user t cnfigure the parameters f a service instance; Schema management used t create, delete and mdify XSD schemas, allwing the user t imprt schemas (frm files, WSDLs r database tables); Transfrmatin management used t create, delete and mdify transfrmatins (XSLTbased). This cmpnent allws the user t create mappings visually with a drag-and-drp interface, using a client-side cntrl; User and permissins management cmpnent used t create, delete and mdify users and dmains; Message Queue management cmpnent used t review the cntents f a service s message queue, allwing the user t remve and re-inject messages; Lgs this is where the users can review the fur different types f event lgs related t cntainers, services, messages and user activity;

6 Device Cnfiguratin in this cmpnent the user is allwed t manage devices knwn by the mail as they ccur r when a certain time/quantity threshld is reached; system and the endpints assciated with each device; System Management Cnfiguratin this cmpnent cntains the cnfiguratins related Alert Cnfiguratin here the user can define alerts assciated with certain events that ccur in a service. The alerts are sent t the user by e- t the autmatic archive and clean-up f lgs and message histry, fr maintenance purpses Figure 3 - Screensht f the Visual Mapper Figure 4 - Screensht f the Orchestratin Management

7 Technlgies Experimental results There were sme initial requirements frm the stakehlders f the system, stating that the system shuld be develped using the.net Framewrk frm Micrsft. With this requirement in mind, all the ther technlgies that were integrated int the system use this framewrk. The NUnit framewrk was used fr supprting the TDD (Test-Driven Develpment) f the dmain mdel and its supprt classes The DBMS used is Micrsft SQL Server 2005 which is ne f the tp 3 mst used in the IT business. [7] The persistence layer was handled with NHibernate, an ORM tl that supprts the DDD (Dmain-Driven Design) apprach used fr mdeling the dmain. MSMQ (Micrsft Message Queuing) was chsen as the MOM implementatin fr its availability in every Windws Operating System since versin 95. WCF was used fr the Web Service implementatin as it can be easily deplyed dynamically, inside a service cntainer. Fr managing HL7 messages, the nly pen-surce library fund was NHAPI, even thugh it has several limitatins (desn t include the cmmunicatin prtcl and hasn t been updated fr a lng time). DICOM messages and bjects are managed with the recent (but gd) mdcm library that includes a cde base gd enugh t implement any DICOM service n tp f it. In rder t evaluate the qualities f the HIE, sme experimental tests were cnducted. The reliability f the system s cmpnents was measured using the MTBF (Mean Time Between Failures) frmula: MTBF = ttal uptime h number f failures The values f the ttal uptime were determined frm the service and service cntainer event lgs in a testing envirnment where stable prttypes are usually deplyed and tested with real-wrld healthcare-related applicatins. Only the failures that actually caused service r service cntainer dwntime were cnsidered. The results f these tests were the fllwing: Tested cmpnent # f instances Ttal uptime (h) # f failures MTBF Service Cntainer Transfrmatin n/a CBR n/a HL7 Receiver HL7 Transmitter n/a DICOM Wrklist SCP (h) DICOM MPPS SCP DICOM Q/R SCU Database n/a Web Service Web Service Caller n/a Table 1 - MTBF Results Mst f the failures than can be bserved in this table were related t bad exceptin handling in

8 child threads f the services and all these prblems have already been slved. tested because they were fully develped by the time the tests were cnducted. On the ther hand, the case f the DICOM Q/R SCU can be justified by the fact that the testing envirnment is the nly ne where this service was effectively tested because f the lack f testing tls. Since all the initial testing f this service was dne here, n wnder the number f failures is s high. The efficiency f the system s cmpnents was measured by the number f messages each service can prcess per secnd with apprximate stress testing appraches. The tests were cnducted in the develpment envirnment using tw PCs: 1. PC with an Intel Cre 2 Du 1.86 GHz and 4 Gb f RAM memry, using the OS Micrsft Windws Vista Business SP2 (64-bit) and the.net framewrk 3.5 SP1; 2. PC with an Intel Pentium D 3.0 GHz and 2 Gb f RAM memry, using the OS Micrsft Windws XP Prfessinal SP3 (32-bit) and the.net framewrk 3.5 SP1; The first machine was always the hst f the services being tested. When external testing tls were needed, like Interfaceware Chamelen HL7 Simulatr/Listener r OFFIS DCMTK Query (C-Find) SCU, the secnd machine was always the ne used fr hsting these tls. The service DICOM MPPS SCP wasn t tested wing t the lack f testing tls, while the services DICOM Q/R SCU and Web Service Caller were als nt The external testing tls were used t test and measure the perfrmance f bth the HL7 services and the DICOM Wrklist SCP service with 500 hundred messages, splitting the lad in threads when pssible (cncurrency testing). The Web service was tested with a test client invking it in 500 backgrund and cncurrent threads. The ther services were tested by injecting 500 messages directly int their message queues. All the tests were cnducted at least three times and the mean value f the results is presented in the fllwing table: Service # f messages Prcessing time (sec.) Messages/ sec. HL7 Transmitter ,858 29,659 HL7 Receiver ,624 4,145 DICOM Wrklist SCP ,703 Web Service 500 7,904 63,259 Database 500 3, ,278 DICOM MPPS SCP DICOM Q/R SCU Web Service Caller Transfrmatin ,24 2,401 CBR 500 1, ,666 Table 2 - Stress test results Mst f the results are either within r abve the expected ranges. The DICOM Wrklist SCP is ne f the slwest, but this isn t a prblem because it is a type f service that will typically receive n mre than 100 requests per day.

9 The results frm the HL7 Receiver were disappinting. This service is using a custm parser t translate HL7 messages t XML which hasn t been ptimized yet, s mre wrk is definitely needed. The results frm the Transfrmatin service were expected since XSLT transfrmatins are cmputatinally heavy. The recmmendatin in this case is t distribute transfrmatins alng the enugh t be used as a part f any integratin engine. Cmparing the features f the HIE and sme f the existing slutins in the market, we can cnclude that this system can already cmpete with several thers in many f the features, althugh the supprt fr sme cmmnly supprted standards is still missing. available Service Cntainers t hardware resurces. Cnclusins maximize the The supprt fr ther standards is prbably the mst relevant future wrk that can be dne t imprve the HIE. The main gals f this wrk were achieved with the develpment f the HIE. The architecture chsen fr the system has been a success, allwing the dynamic deplyment f integratin services in the service cntainers and letting the user distribute the services accrding t the available hardware resurces. The system was develped in a mdular fashin, making it easy t change a part f the system withut cmprmising the rest. There are als several extensibility pints that can be used t imprve the system s features. One f the defining pints f the system is the Base Service that prvides an easy integratin with the rest f the system, allwing a develper t cncentrate nly n the new features that add business value t the system. Althugh the HEI is meant fr healthcare Bibligraphy 1. KHOUMBATI, K.; THEMISTOCLEOUS, M.; IRANI, Z. Evaluating the Adptin f Enterprise Applicatin Integratin in Health-Care Organizatins. Jurnal f Management Infrmatin Systems, Vlume 22, Issue 4, GEE, T. Current State f Medical Device Cnnectivity. Medical Cnnectivity, 13 Junh Dispnivel em: < 3. MOTOROLA. Enterprise Integratin: A Key T Successful Public Sectr Custmer Service. [S.l.], p CHAPPELL, D. Enterprise Service Bus. Sebastpl, EUA: O'Reilly, BUSCHMANN, F. et al. Pattern-Oriented Sftware Architecture. [S.l.]: Wiley and Sns, v. 1, HERNAN, S. et al. Uncver Security Design Flaws Using The STRIDE Apprach. MSDN Magazine, Nvembr MARKET MAGIC RESEARCH RDBMS Sftware Cst f Ownership Study. [S.l.], p envirnments, the cre f the architecture is generic