Smart Hospital Management System: An Integration of Enterprise Level Solutions

Utilising Open Group Architecture Framework (TOGAF)

Zenon Chaczko, Christopher chiu and Avtar Singh Venkatesh Mahadevan

Kohli Faculty of Higher Education,
Faculty of Engineering and IT, Swinburne University of Technology
University of Technology Sydney Vic 3140 Australia
NSW 2007 Australia vmahadevan@swinbume.edu.au
zenon.chaczko@uts.edu.au, christopher.chiu@uts.edu.au
and avtar.s.kohli@uts.edu.au

Ahstract-A significant portion of the Hospital Information • Migration Planning

Systems currently consists of various individual legacy • Implementation Governance
applications that have to be integrated, to deliver a more
• Architecture change Management
unified solution. The performance, reliability and other factors
The Architect iterates through these phases and analyse
of these applications can alter the performance, reliability and
contextual information which aids requirements management,
other characteristics of integrated Solution, the Smart Hospital
as shown in figure attached.
Management System (SHS). The actual evaluation of these
Architecture
parameters of these applications is outside the scope of this Context
Iteration
document. The SHS being an infrastructure component relies
heavily on the actual resources made available to it for its
proper functioning, operation and maintenance. This article Architecture
Definition
Architecture
aims to deliver an approach in architecting solutions which can Governance
Iteration

be utilised as framework to address common issues in

integration of enterprise level solutions. The methodologies
discussed in TOGAF version 9 are utilised to demonstrate the
feasibility of proposed solution. This paper introduces the
problem space/scenarios, constraints, requirements, enablers,
risks, sample legacy application architectures and proposed
integration solution presented with TOGAF components. The
growing number of waiting lists, rising pressure on medical
professionals and accountability for medical negligence are
only part of the motivation to take initiative towards holds a
core model integration strategy in various legacy
infrastructure systems.

Keywords-Smart Hospital System, the Open Group

Architecture Framework (TOGAF), Integration Frameworks,
Service Oriented Architecture (SOA) Fi�lre: Iteration Cyclel>

Figure 1. Iteration Cycles

I. INTRODUCTION

The Smart Hospital System is a solution aimed to present A. Phase 1: Architecture Vision:
architecture Integration Framework using TOGAF's
As detailed in the SHS Project Proposal document, the
Architecture Development Method. The key to TOGAF is
main business mandates for the SHS are to build a new IT
the TOGAF Architecture Development Method (ADM) - a
Integration Platform/framework that shall be able to:
reliable, proven approach for developing enterprise
• Respond to new business demands of the
architecture descriptions that meets the needs of the specific
organisation (HospitalslMedical facilities) for
business. There are 8 phases to the TOGAF core model
the future (Scalability/new applications/new
which include:
devices/ more users).
• Architecture Vision
• Deployed quickly at any new location within
• Business Architecture
restricted time frame, and with minimal
• Information Systems Architecture
configuration and no new development /
• Technology Architecture
customisation required.
• Opportunities and Solutions

978-1-4244-5540-9/10/$26.00 ©2010 IEEE

8
 • Be able to reliably service the current workload
for urban hospital serving a population of I
million i.e. up to 10,000 user accounts, up to
200 concurrent users. Along with the new
workloads projected of up to 100,000 user
accounts and up to 5,000 concurrent users.
• Provide 99.999% availability (which equates to
5 minutes of downtime in a year).
• Fast and efficient enough to be able to
simultaneously service several hospitals and
mobile units in geographically diverse areas of
the country.
• Have no additional operational costs compared
to the current infrastructure.
• Provide a single VI from all the applications to
the user.
• Integrate the current Sample application Patient
Management System (PMS) and Accounting
and Payroll Package (APP) applications with
minimal effort.
• Provide flexibility in choice of application
providers, to avoid vendor lock-in.

B. Phase 11: Business Architecture:

The following Figure 2 is just a scaled down version of
the problem sEace.
,--------------------,
Smart Hospital Management System

External System

Figure 3. Components of the legacy application APP

Figure 2. The Boundary Context Model of the SMHS

Administrator: A user who has administrators privileges

to the HSIF. Access is provided to all applications and
components within the SHS. The administrator has access to
administration and maintenance functionalities within SHS.
Standard User: A user with no administrator privileges to
the SHS. Restricted access is provided through the Unified
Interface only. No HSIF functionalities are surfaced to this
user. Users have access based on their user profile to specific
functionalities within the existing PIMS and ERP systems
(legacy systems); however this access will be mediated via
the HSIF.
External System: An external system that can access
specified services through Application Integration
Framework. The following are the Architectural
representations of PIMS and AAP for visual aid:
Clients Server

Figure 4. Components of the legacy application PMS

9
C. Phase III: Information System Architecture: location of where the data exists (which legacy data store).
The Business Service component, will query the Enterprise
PlIlSA;ip:cafonaooDa'.a
ComponentS 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 carry out
the requested task.

D. Phase I V:: Technology Architecture:

i
I
10
PIMS Application and
111

I
Data Components
I o

-QWelrserieelrllelface
-�Sendl.oca:y
..-. localR�Response
.. • �etNCrtRequestiResponse

Figure 5. SHS Integration Architecture (Conceptual View)

The SHS Database is an aggregation of the Database

Components of all the SHS Applications deployed in the
system. This is hosted on the SHS Database Server. The APP Application and
Application Components of all the SHS Applications Data Components
deployed are hosted on SHS Application Servers which have
o
an SHS Agent each. Each agent knows the SHS Application
Components that are available on the server. The SHS
Interface Server hosts SHS Website and the SHS Web
services. The website is an aggregation of the entire website
based VI's of all the deployed SHS Applications. The web
services of all the deployed SHS Applications are similarly
egend -------..
aggregated, and both these aggregations are hosted on the
--0 Web·service Interlace I...=
.:: ==--�==::::....)
::!...
SHS Interface Server. The SHS Server is a centralized server
-t Send local�
application that interacts with all the SHS Agents in the
+-+ local RequesVResponse
system, and orchestrates the application integration process. � ---. Network Request/Response
Currently, the two applications are operating separately
without sharing any data. As such it is possible that some
Figure 6. Execution view of SHS
data is duplicated in the two applications' data stores. This
brings up issues of merging of such data. Although this could
Evaluation of technology Architecture:
be a temporarily problem for the life of the legacy
Evaluation Criteria: The Evaluation was based on
applications in their existing structure, this problem needs to
Research on available runtime environments which are of
be addressed.
enterprise scale and crossing checking the
The Architecture Team considered two solutions to this
reviews/pros/cons/stability from various accompanying
problem:
documentation and blogs by originators.
Data Rewrite: This required manually reconciling
Evaluation Methods: The idea of choosing lIS 7 and
conflicting data in the two data stores, and modifying the
JBoss 5.2 are more related to what suits best in a Enterprise
associated business logic to conform to this. This approach is
level Application runtime for applications(legacy/proprietary)
not suggested as it is too intrusive of the legacy applications,
written in Java/C#IC++. The lIS was obvious choice as the
and can pose a major risk to the stabilities of these
Application "PIMS", is written in .Net which requires a
applications.
Microsoft Windows runtime environment. For the "APP",
Data integration using a separate database: This
JBoss 5.2 was chosen as a deployment server of choice
approach envisages a separate data store called Enterprise
which is a significant upgrade from jetty/apache/tomcat.
Data Integration Service which will contain information for
data mapping amongst the existing legacy data, as well as the

10
 E. Phase V:: Opportunities and Solutions:
The opportunities presented by the integration solution
can be viewed in form of core quality attributes, which can
be considered:
Performance: The clear separation of middleware that
uses high-performance enterprise-class message queuing
solution results in this component being a performance
enabler. The use of web-services for other messaging
(especially internal) results in this factor becomes a
performance constraint. However, this can be managed by
using web-servers having sufficient capacity for the
projected loads. Caching of service endpoints, scale-out of
web components based on performance requirements, use of
enterprise class technologies.
Usability: A separate module dedicated to providing
management services of the system is an enabler for the
usability attribute. A separate module for the Instrumentation
Logger is yet another enabler for usability. This will allow
system administrators to easily track transactions through the
system for the following purposes Troubleshooting,
Debugging and Auditing (for compliance to organisational
processes, and for statutory compliance). Other enablers
Figure 7. Deplyment view of SHS listed below have to be developed as part of the HLD and
LLD. These can be either scripts or software modules with
Benefits: The core benefit of a hybrid approach of user interface.
running 2 separate runtime Environments and an ESB to Reliability: Runtime reliability shall be ensured in the
allow seamless request/response style integration, include system by having redundant failover modules identified and
Less Development/modification on API on existing legacy implemented during deployment. Stateless services allow
systems and Clear separation of middleware, improves load-balancing of critical components using specialised
performance (logical Queues) /security (Separate single sign hardware devices. Non-runtime reliability shall be assured by
on(SSO) module + HTTPS connections). having all newly developed modules specifically designed to
Pitfalls: The scalability of the system (adding more cater to the boundary conditions of Initialisation, Failure,
independent web applications) would pose major Recovery and Termination.
configuration surgery, if implementation does not address Security: The entire SHMS System shall be deemed to be
Data synchronization issues appropriately. Due to extensive running within a corporate firewalled environment. The
use of web services the Performance/Quality of service may Security aspect is covered from 5 angles: single sign on
be hampered if the transfer of large files is between systems which is on authentication gateway, encrypted data access
(format conversion may be an issue within 2 within Business services, Random queue number allocation
applications .e.g. .odt to .docx formats or large image file by message broker, Double firewall and Instrumentation
formats). Logger for auditing attacks. It shall employ a layered
Technological constraints: The execution of APP on architecture with critical assets in the inner area:
JBoss i.e. running on a UNIXILinux server and lIS running
'"
on a Windows server and the integration (ESB) supporting 2
Qj
applications deployed on these 2 very different runtime 1: '"
Q) Qj
environments, may cause Developers a some grief: like '"
1:
Cl Q)
windows slashes("/") and Linux slashes("\"), maintaining the c: '"
'0
consistency between DatelData formats. The processing .l!! Qj
c:
times may hugely vary and depend on legacy applications C c:

internal performance/dependencies. External Firewall e Corporate Firewall

LL
Enablers: The availability of source code for the legacy
systems and other available resources to build a suitable ESB
Figure 8. Security context of the SHMS System
that meets all stakeholder needs. The Clear separation of
application components, middleware and (System/user) Data
shall allow developers to make a head start on integration F. Phase VI:: Migration Planning:
process through ESB and web services.
The SHS aims to smooth out any incompatibilities by
following a migration plan which aims to address common
issues/challenges faced by enterprise level amalgamation of
applications include:

11
 Adaptability: The use of generic components [3] Java EE and .NET Interoperability, Integration strategies, patterns and
Best Practices, Marina Fisher, Ray Lai, Sonu Sharma, Laurence
infrastructural components.
Moroney, Prentice Hall, Sun Microsystems Press, 2006
Simplicity: The proposed architecture uses the minimum
[4] IT Architecture and Middleware, Strategies for Building Large
no. of components in the simplest possible way.
Integrated Systems, Second Edition, Chris Britton, Peter Bye,
Flexibility: The modular architecture proposed can be re­ Addison-Wesley 2004
combined, enhanced, and scaled-out in a wide variety of [5] http://msdn.microsoft.comlen-us/library/ms954595.aspx Application
ways, giving flexibility at deployment and maintenance time. Architecture for .NET: Designing Applications and Services, Last
Modularity: The use of layers, components, and other visit 411112009

techniques aid in a highly modular internal structure, [6] https:llwww.ibm. comldeveloperworks/library/ws-esbscenl

enhancing overall system reusability. Understand Enterprise Service Bus scenarios and solutions in
Service-Oriented Architecture, Part I, The Role of Enterprise Service
Consistency: The consistent use of the underlying
Bus, last viewed 4/1112009Gunasekaran A., B. Kobu (2002), Citation
philosophy behind designing the component responsibilities from [8], pp25-24.
and interfaces, and special attention being given towards
achieving a final list of nearly equal-sized components
enhances reusability, and the overall aesthetics of the
proposed architecture. Appendix: Details of components:
Orthogonality: The clear-cut responsibilities of the
various components, without any overlap, aids in the
orthogonality of the components within the overall system An integration platform that aligns
boundary. hospital business strategies with IT
For Details on component level responsibilities see investments through unification of
appendix. hospital's existing core applications
(Patient Management System and
G. Phase VII:: Implementation Governance Accounting and Payroll System),
Smart Hospital
Pending providing a single point of access via
System (SHS)
implementation of a single UI (can be
H. Phase VIII:: Architecture Change Management web based or rich-client) and enabling
Pending future integration of other systems
(existing systems, or future
II. CONCLUSION deployments) into the Hospital's IT
ecosystem.
The objective of this paper has been achieved by
A published set of specifications for
investigation into various available architecture
SHS Application software applications that have to be
models/frameworks and patterns that fit the category of
Development conformed to, III order for them to
integration facilitators, with a vision of the future demands Standard integrate with the HSIF. Also provide
for scalability and extensibility. While SHS is aimed to interface description for HSIF.
adequately meet all the stated and implied requirements, Combination of the existing user
TOGAF supported in less rework on the existing applications interfaces enabled to communicate via
to fit into the new framework. It also provided a smoother web-services using web service proxies
transition of the system from the immediate role of an that interface with the Message Router
application integration framework for legacy applications, to User Interface within Enterprise Service Bus (ESB).
its eventual role as a pure application integration framework. This is the interface for users to access
Thus, HSIF shall be deemed the proposed architecture of the existing legacy functionality as well as
Architecture Team. any future additional application via the
The proposed architecture - the HSIF - meets the HSIF.
business case requirements and allows existing systems Management user interface to enable
(APP and PMS) to be open for feature rich front-end which maintenance and administration tasks

provides secure interfaces. Therefore, both recent required to be carries out by the
administrators of HSIF. This user
developments and our research outcomes in this field project
interface is developed as part of this
are found to be very encouraging. However, more Management UI
project for management of all the in­
investigation is required before full confidence and wider
house developed components of the
acceptance is to take place in the ICT industry.
ESB. Vendor supplied technologies
used within the ESB will have their own
REFERENCES
management interface.
[I] Reekie, John and McAdam Rohan, A Software Architecture Primer,
Any business service or third-party
2005, Angophora Press.
External Service application that will be authorised to
[2] Applied SOA, Service-Oriented Architecture and Design Patterns,
Requesters access specified hospital services using
Michael Rosen, BorisLubinky, Kevin T. Smith, Marc J. Bac1er, Wiley
HSIF.
Publishing Inc. 2008

12
 First point of access for the VI and
External service requesters which will
dynamically locate the appropriate
service requested and route the request
accordingly. Message Router, mediates
communication and service calls to
Message Router
provide a separate contract with the Combines the various eXlstmg services
service requesters and the service across multiple legacy applications (PIMS
providers. This separation of service and APP) into a higher level business
contracts enables changes in the service Service service. Service Choreographer hides the
providers with minimal effect on the Chorographer granularity of the existing legacy
consumers. functionality into more atomic SOA like
services in line with future direction of the
hospital.
Repository of services available in the
Constitutes business services designed to
hospital services ecosystem. Service
align to the hospital business requirements
Service Directory directory will enable service location
based on to encapsulate the legacy
transparency in conjunction with the
Business Services application API calls into an aggregated,
Message Router.
higher level, and atomic service call. Each
Make a selected subset of hospital's
business service is the invocation point for
B2B Gateway services available to external organisations
the lega�functionality.
in a controlled and secure manner.
Describes and coordinated the workflow of
The management engine that the Business
how services interact (legacy and new),
Management VI interfaces with in order to Workflow
including the logic and the order of
carry out administration and maintenance Orchestration
Management interactions.
operations on the custom components of
Module Provides for data integration by mapping
the ESB. This Module may not be required Enterprise Data
the relevant information from the legacy
depending on the choice of technology Integration Service
system
used to build the ESB.
Business logic layer of existing Patient
Collection of Message Router, Service
Information Management System in the
Directory, Instrumentation Logger and the hospital. The business functionalities
Management Module which carries out the PIMS Business
Enterprise Service contained in this layer are to be web service
core integration responsibilities within enabled for integration with the other
Bus
HSIF and enables future progression of systems in the hospital via HSIF.
hospitals IT ecosystem towards a more
standard Service Oriented Architecture.
Provides authentication (does user have
access?) and authorisation (what user has
access to?) services for the hospital as a
Single Sign-On whole, enabling a users to have a single
credentials for accessing multiple legacy
applications and new systems deployed in
future.

13
 Business logic layer of eXlstmg
Details of SUS component Interfaces
Accounting and Payroll System in the
hospital. The business functionalities
APP Business
contained in this layer are to be web
service enabled for integration with the
other svstems in the hospital via HSIF.
Business components that provide
the existing functionality within their
application. The purpose of this project Interface
Description
Business is to integrate the functionality of these no.
Component components transparently and provide
access via a single user interface. The Web-service interfaces between UI, external
internal functionality of these service requesters and the Message Router. This
components is not required at this level. interface is responsible for mediating requests from
service consumers to the service providers by being
APP and PIMS Existing databases of each legacy
Databases application in the hospital. the first and only point of contact between service
1,2 consumers and the Enterprise Service Bus (ESB).
The advantage of the separation of the service
Data Access DAL Layer of existing Accounting
provider interfaces to the UI is that the consumer
Logic Components and Payroll System in the hospital.
service contracts and policies will not have to
change by changing the service providers and/or
Data Access components that
Data Access their service contracts.
provide data access to the application
Logic Component External organisations that consume some services
data store. 3
provided by the hospital
APP Data Legacy Accounting and Payroll
Store Database Web-service interface between the management
User Interface and the Management Module of the
4
ESD. The management module will only control
PIMS Data Patient Information Management
the custom developed component of the ESB.
Store System Database
Web-service interface of SSO is invoked by
Message Router in order to authenticate the request
Any service or application 5
as well as retrieve the callers roles based access
component already listed in this table
Service or profile.
that is required to be monitored and or
Component Once a service request is received by the Message
audited for performance, errors and or
exceptions. Router and authenticated and etherized by SSO,
Persistence message queue which message router will request the most suitable
Message
service or component that are being 6 service provider for processing the request by
Queue
monitored will submit events to. engaging the Service Directory and receiving the
A service that will read the service end-point where it will forward the request
Instrumentation submitted messages submitted from the to.
Logger message queue and writes them to the
instrumentation database. B2B gateway will relay the external client's request
7
Web user interface to display the to the message router for appropriate action.
Instrumentation
instrumentation information in the
UI
database Management Module will send a command to the
modules it can manage and will receive the
8
outcome of the request (failed, succeeded) and
execution details.

ESB will invoke the appropriate business service

9
based on the request message.

In case the service request if for a long running

process and required a business workflow, ESB
will forward the request to the Business Workflow
10
Orchestration which will take the request through
the appropriate business workflow process and
return the results once completed.

14
 Orchestration invokes legacy functionality via
11
the business service.

Business service invokes the legacy

12,14 functionality through their web-service
interfaces
Business service queries the enterprise
database (before legacy systems) to locate
13 where the required information lives (which
legacy system) and get the appropriate data
record keys

Service or application components that are

15 setup for monitoring will send a status
message to a message queue

Instrumentation service that reads the

16 messages in the queue and writes them into
the instrumentation database

Instrumentation interface will read the

17
information from the database for display

15