Evolutionary Architectural Model of Middleware

Chiu, Kohli and Chaczko:Middleware Integration Model for Smart Hospital System Using TOGAF

for Construction of an Intelligent Health System

Zenon Chaczko1, Essam Rahali2, Christopher Chiu3, and Avtar Singh Kohli4

Abstract—Health Information Systems in industry are undergoing a paradigm shift in uniformity. The needs for health professionals to utilise universal patient records require various legacy health applications to be integrated in a logical and orderly process. The Smart Hospital Management System is an infrastructure solution that aims to unify health patient management subsystems together while retaining the existing performance and reliability requirements of the individual components. The infrastructure oriented application of The Open Group Architecture Framework, presented in this research work, ensures that integrity and the industry-oriented views are considered throughout the development process. This includes a consideration of the problem space, context and scenarios, requirements, constraints, risks, enablers and inhibitors of the legacy application architectures. The proposed integration solution with TOGAF components, addresses the need for industry and enterprises health institutions to unify their legacy operations in a consistent and best practice compliant manner to ensure their data records are thorough, comprehensive and provide robust security mechanisms to make certain that privacy regulation, compliance and protection against identity theft are vital. Keywords—Smart Hospital System, Open Group Architecture Framework (TOGAF), Integration Frameworks, Service Oriented Architecture (SOA)

I.Introduction

The consolidation of health information records has primarily been driven by the need of industry compliance to reduce data duplication and prevent inconsistency in patient information. A further motivation is also to provide convenience to health professionals and patients to easily access records in simplified manner. The Smart Hospital System (SHS) is a unifiedsolution aimed at presentingan architectural integration framework using The Open Group Architecture Framework (TOGAF) Architecture Development Method Version 9.0[14].

The main concern of TOGAF is the Architecture Development Method (ADM), which seeks to developenterprise architecture descriptions [14] that meet the needs of the health industry stakeholders. The diagram below depicts the TOGAF methodology which has been employed to ensure the integration of legacy health applications is executed in a coordinated manner, with minimal disruption to current health operations. An assessment of the integration build is detailed in Section 9 of this document, using the Architectural Trade-off Analysis Method (ATAM) [17]. Iteration through theeight phases of the TOGAF core model are accomplished to ensure contextual information is obtained to aid in requirements management:

Architecture Vision (Section 2);
Business Architecture (Section 3);
Information Systems Architecture (Section 4);
Technology Architecture (Section 5);
Opportunities and Solutions (Section 6);
Migration Planning (Section 7);
Implementation Governance (Section 8); and
Architecture Change Management (Section 9).

Fig. 1.Iteration Cycles of the TOGAF Model[14]

II.ArchitectureVision

Thearchitectural vision for theSHSIntegration Project consist of the core business mandates to re-engineer a new IT Integration Platform and Framework that unifies legacy applications with support for new services to the meet future needs of the health institution. TOGAF’s ADM is comprehensive and flexiblein achieving required perspectives like technology, data, business and application level requirements. Unlikeother enterprise scale frameworks and practicessuch asZachman[18], Federal Enterprise Architecture (FEA)[4]or Gartner[13], they were found to be less suitable as they require more documentation and far greater reliance on domain experts.

Fig. 2.Zachman Matrix Grid[18]

Zachman Framework defined architecture can only be considered complete when all the cells of the grid are complete with valid information sets as shown above, this may not be feasible in the context of integration projects where specific points at initial stages are unclear. As for FEA depicted below, the complexity and demands for all taxonomies[4]to be generated as a resultant set of elaborate, cross-agency reference models consist of thefive core reference models (RMs): Business, Component, Technical, Data and Performance [4]. The FEA process is aimed at the development of segmented architectures which is a four-step process of architectural analysis, design, investment strategy and project management. In comparison to FEA, TOGAF’s ADM has nine iterative steps which can be tailored to project needs [12].

Fig. 3. FEA Model[4]

The nature of the problem statement, in terms of integration demands that enterprise scale integration to be vendor neutral and be process complete[12], is that TOGAF is ranked highest by formalizing the requirements of the SHS stakeholders. Furthermore, prioritizing the business domain needs will improve the efficiency of existing patient healthcare practices, while catering for future demands on the SHS system are considered from a holistic perspective[10]. They have been identified in terms of responsiveness, flexibility, reliability, robustness and cost-effectiveness:

Responsive to Future Needs:
Respond to future business demands of the health institution; including scalability for new applications, devicesand users;
Deployable to New Locations:
Be deployed quickly at any new location within a restricted timeframe, and with minimal configuration and no new development or customization required;
Reliable for High Workloads:
Reliably service a current workload for a centralized hospital serving a population of up to 1 million; that scales for a minimum 10,000 user accounts and 200 concurrent users to potential new workloads projected of up to 100,000 user accounts and up to 5,000 concurrent users;
Available in Uptime:
Provide 99.999% uptime availability, equating to a total of5 minutes of downtime in a year;
Efficient to Service Multiple Locations:
Be efficient enough to be able to simultaneously service several hospitals and mobile units in geographically diverse areas of the country;
Cost Effective:
Have no additional operational costs compared to the current infrastructure;
Unified in Accessibility:
Have a single unified UI from all applications;
Compatible with Legacy Applications:
Integrate the current legacy applications, including thePatient Management System (PIMS), Accounting and Payroll Package (APP) and Enterprise Relationship Package (ERP) applications with minimal effort; and
Flexible in Application Providers:
Provide flexibility in choice of application providers, to minimize vendor lock-in.

III.Business Architecture Model

The Business Architecture Model identifies the main users of the SHS system, to create a boundary context model from a high-level perspective. This ensures the relevant stakeholders are identified in the finalizedarchitecture model[6][15]. The following diagram depicts the main actors of the SHS problem space, and their interaction with the main subsystems and legacy application services:

Fig. 4. The Boundary Context Model of the SHS

A.Administrator

A user with administrator privileges to the SHS; access is provided to all applications and components within the SHS. The administrator has access to complete administration and maintenance functionalities.

B.Standard User

A user with no administrator privileges to the SHS; restricted access is provided through the Unified Interface only. No SHS functionalities are available to this user. Users have access based on their user profile to specific functionalities within the existing legacy PIMS, APP and ERP systems.

C.External System

An external system that can access specified services through the Application Integration Framework. The following figures include the legacy architectural representations of PIMS and APP platforms:

1)Accounting and Payroll Package System

The accounting and payroll system is responsible for the financial accountability of the health institution. Financial records of patients, including private and public insurance details, along with drug inventory management and patient billing information is stored in a common data store layer. The two core interfaces of the system include an Accounting System Interface for third-party financial packages and an External Reporting Interface for governance and legal compliance purposes to the relevant health department authorities.

2)Patient Information Management System

The PIMS platform is a three-tiered architecture that consists of an interface layer front-end, a middleware layer for business service hosting and management, and a data-store layer containing patient information, staff payroll data and equipment data store. A web service request handler is an enterprise service bus to manage the suite of business services of patient health records, diagnoses, staff to patient associations and medical infrastructure record management.

Fig. 5. Components of the APP Legacy Application

Fig. 6. Components of the PIMS Legacy Application

IV.Information System Architecture

Fig. 7. SHS Integration Architecture (Conceptual View)

The SHS Database is an aggregation of the Database Components of all SHS Applications deployed in the system. The deployed SHS Application Components are hosted on SHS Application Servers which are bound to each SHS Software Agent. Each agent is aware of the SHS Application Components that are available on the server. This is achieved through a synchronous association between the business services and business orchestration data store. The purpose of this association is to harmonies PIMS patient records with the APP medical department billing records against each patient.

The SHS Interface Server hosts the SHS Web Portal and the SHS Web Service. The web services of all the deployed SHS Applications are aggregated according to complimentary functionality, and both these aggregations are hosted on the SHS Interface Server. The SHS Server is a centralized server application that interacts with all the SHS Agents in the system, and orchestrates the application integration process. Physical redundancy of the SHS Server is achieved through a primary and backup server with hardware fail-over, while database backup schedules are performed nightly. Secure remote maintenance by technical administrators ensures for regular and continuous vigilance against security intrusions and denial-of-service attacks on the system.

Currently, the service applications are operating separately without sharing medicaland patient information records. Due to the high likelihood of data duplication in the data-stores of the applications, this would result in increased physical data management overhead and potential conflicts between common patient records, thus resulting in the inevitable concern of merging the legacy entities together.

Furthermore, maintenance costs must be minimized to ensure the feasibility of implementing the middleware integration model in a seamless manner. Otherwise, this will result in a significant investment in the health institution’s IT infrastructure needs. This is an unrealistic consideration, noting that the purpose of implementing a middleware integration model is to achieve cost efficiencies, and as such it should be clearly demonstrable that savings can be achieved in system maintenance and end-user usability. In light of these concerns, two final candidate solutions were considered:

A.Data Rewrite

This requiresa manual reconciliation of conflicting data in the data stores, and modifying the associated business logic to conform to this. This approach isnot considered as a long-term solution as it is potentially intrusive to the legacy applications, and can pose a major risk to the stability of these applications.

B.Data Integration via Separate Database

This approach envisages a separate data store called the Enterprise Data Integration Service which will contain information for data mapping amongst the existing legacy data, as well as the location of where the new and legacy data exists. The Business Service component will query the Enterprise Data Integration Service upon receiving a client request, in order to find the location of the required information to service the client request. This information is then used to invoke the appropriate legacy application logic to perform the requested task.

V.Technology Architecture

The evaluation of technology architecture is essential in determining the final implementation model, as technology inherently drives the design and infrastructure concerns [16]:

A.Evaluation Criteria

The evaluation was based on researching available enterprise-scale environments and cross-checking the reviews, advantages, constraints and stability from various accompanying documentation and research studies by the authors. Investigative interviews with medical personnel and management staff is necessary to establish clear guidelines on determining appropriate criteria to consider in this process.

B.Evaluation Methods

The purpose of selecting IIS 7 and JBoss 6.0 is related to the suitability ofan Enterprise-level Application runtime for legacy and proprietary applications written in the Java, C# and C++ programming languages. IIS is used as PIMS is written in the .NET Frameworkwithin the Microsoft Windows operating environment[9]; while APP operates in JBoss on a UNIXdeployment server, which was considered to be more suitable in comparison to Jetty, Apache or Tomcat deployment services[5]. In addition, the added breadth of legacy operating system platforms being used require key subject-matter experts to consider the risks of using particular software technologies in the final middleware implementation.

C.Benefits

The core benefit of a hybrid approach of running separate runtime environments and an ESB to allow seamless request/response style integration, include less development and modification on the API’s of existing legacy systems and clear separation of middleware[1], improves performance (logical queues) and security [3](Separate Single Sign-on (SSO) module and Encrypted HTTPS connection). This ensures that all users can be monitored effectively and efficiently in a secure manner, while maintaining a consistent interface to allow medical staff to perform their desired operations in the SHS.

Fig. 8. Execution View of the SHS

Fig. 9. Deployment View

D.Drawbacks

The scalability of the system, by adding more independent web applications, would pose major configuration surgery if implementation does not address data synchronization issues appropriately. Due to the extensive use of web services, the indicative factors of Performance and Quality of Service may be impacted due to the transfer of large data structures between systems. One common example is the format conversionbetween two applications, such as image conversion of x-ray, ultrasound, computer-assisted tomography scans and magnetic resonance imaging scans.

E.Technological Constraints

The execution of APP on JBossand PIMS on IIS, along with the integration Enterprise Service Bus (ESB) supporting two applications deployed on these diversified runtime environments, may cause developers potential programmatic concerns. Common problem include the differences of directory separator symbols (i.e. Windows (“/”) and UNIX(“\”)), and maintaining the consistency between Date and Data formats. The processing times vary in a live-environment and depend on the legacy application’s internal performance and system dependencies, which will have consequential effects on the performance compliance of the finalized SHS system.

F.Enablers and Inhibitors

The availability of source code for the legacy systems and other available resources to build a suitable ESB that meets all stakeholders needs to be considered. The clear separation of application components, middleware and medical domain data allow developers to make initial strategies on integration process through the ESB and web services in a seamless manner. This ensures that quality is continuously maintained throughout the development process. In some cases,limited low-level design considerations as well as poorly documented source code can cause not only serious delays, but even inhibit possible (time related) opportunities.

VI.Opportunities and Solutions

The opportunities presented by the integration solution can be viewed in form of the core quality attributes of the SHS system. This takes into consideration the performance, usability, reliability and security attributes and the architectural solutions to address the relevant concerns:

A.Performance

The clear separation of middleware that uses high-performance enterprise-class message queuing solution results in this component being a performance enabler. The extensive use of webservices for other messaging (especially internal communication) results performance constraints. The design of the messaging modules should employ today’s intelligent asynchronous middleware technologies such as AMPS to minimize volume of wasteful queries[8]. Data security compliance and extensive traffic across modules means more performance constraints across system units. However, this can be managed by using webservers having sufficient capacity for the projected loads. Caching of service endpoints, scale-out of web components based on performance requirements and enterprise technology use need reflection.

B.Usability

A separate module dedicated to providing management services of the system is an enabler for the usability attribute. Implementation of a user controls which are minimalistic from provisioning and command initiation perspective yet powerful enough to minimize guesswork, are very much the aim of defining such requirements which guide developers to design ergonomic process flows. A separate module for the Instrumentation Logger is an additional enabler for usability, such that audits can be conducted without impacting on the overall maintenance of the SHS system. This will allow system administrators to easily track transactions through the system for the following purposes: Troubleshooting, Debugging and Auditing (for compliance to organizational processes, corporate governance and statutory compliance).

C.Reliability

Runtime reliability shall be ensured in the system by having redundant failover modules identified and implemented based on projected data traffic. The redundancy adds extra cost and maintenance which be taken into account while configuring data retention schedules. The failover data links, load balancers, mirrored disks, back up servers to cover hardware infrastructure is insufficient where software middleware/agents are prone to synchronization issues, data corruption and security threats on core connections. Defining requirements around data integrity for verification of keys/ids/credentials and records validation without forming new bottlenecks is important. This ensures that both software and hardware redundancy criteria is met in the middleware integration model, a key factor in achieving 99.999% reliability mandates. Stateless services allow load-balancing of critical components using specialized hardware. Non-runtime reliability shall be assured as all newly developed modules are specifically designed to cater to the boundary conditions of: Initialization, Failure, Recovery and Termination.