Building an Intelligent Health System Using an Evolutionary Architectural Model of Middleware

International Journal of Advanced Computer Science, Vol. 2, No. 2, pp. 56-64, Feb. 2012.

Manuscript Received:

25,Jun., 2011

Revised: 7,Sep., 2011

Accepted:

7,Jan., 2011

Published:

15,Mar.,2012

Keywords

Smart

Hospital

System,

Open Group

Architecture

Framework

(TOGAF),

Integration

Frameworks,

Service

Oriented

Architecture

(SOA)

Abstract Health Information Systems in

industry are undergoing a paradigm shift in

uniformity. The needs for health professionals

to utilize universal patient records require

various legacy health applications to be

integrated in a logical, orderly process. The

Smart Hospital Management System is an

infrastructure solution that seeks to unify

health patient management subsystems

together while retaining the existing

performance and reliability requirements of

the individual subsystems. The infrastructure

oriented application of The Open Group

Architecture Framework, presented in this

research work, ensures that integrity and an

enterprise-level perspective are considered

throughout the development process. This

includes a consideration of the problem space

and scenarios, constraints, requirements,

risks, enablers and inhibitors of the legacy

application architectures. The proposed

integration solution with TOGAF

components, addresses the need for health

institutions to unify their legacy operations in

a consistent and best practice compliant

manner to ensure universal patient records

are thorough, comprehensive and provide

robust security mechanisms to make certain

that privacy regulation compliance and

protection against identity theft are vital.

1. 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 unified solution aimed at presenting an

architectural integration framework using The Open Group

Architecture Framework (TOGAF) Architecture

Development Method Version 9.0 [1].

The main concern of TOGAF is the Architecture

Development Method (ADM), which seeks to develop

enterprise architecture descriptions [1] that meet the needs

Christopher Chiu, Avtar Singh Kohli and Zenon Chaczko are with the

University of Technology, Sydney, Faculty of Engineering & IT

([email protected], [email protected],

[email protected].)

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 paper, using

the Architectural Trade-off Analysis Method (ATAM) [2].

Iteration through the eight phases of the TOGAF core

model are accomplished to ensure contextual information is

obtained to aid in requirements management:

A. Architecture Vision (Section 2);

B. Business Architecture (Section 3);

C. Information Systems Architecture (Section 4);

D. Technology Architecture (Section 5);

E. Opportunities and Solutions (Section 6);

F. Migration Planning (Section 7);

G. Implementation Governance (Section 8); and

H. Architecture Change Management (Section 9).

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

Building an Intelligent Health System Using an

Evolutionary Architectural Model of Middleware Christopher Chiu, Avtar Singh Kohli & Zenon Chaczko

Christopher Chiu et al.: Building an Intelligent Health System Using an Evolutionary Architectural Model of Middleware.

International Journal Publishers Group (IJPG) ©

57

2. Architecture Vision

The architectural vision for the SHS Integration 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 flexible in achieving required

perspectives like technology, data, business and application

level requirements. Unlike other enterprise scale

frameworks and practices such as Zachman [3], Federal

Enterprise Architecture (FEA) [4] or Gartner [5], they were

found to be less suitable as they require more

documentation and far greater reliance on domain experts.

Fig. 2. Zachman Matrix Grid [3]

Fig. 3. FEA Model [4]

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 the five

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 [6].

The nature of the problem statement, in terms of

integration demands that enterprise scale integration to be

vendor neutral and be process complete [6], 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

[7]. 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, devices and 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 of 5 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

the Patient 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.

International Journal of Advanced Computer Science, Vol. 2, No. 2, Pp. 56-64, Feb. 2012.


58

3. 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 finalized

architecture model [8]-[9]. 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

1.) 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.

2.) 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.

3.) 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:

A.) 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.

Fig. 5. Components of the APP Legacy Application

A.) 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. 6. Components of the PIMS Legacy Application



59

4. Information System Architecture

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.

Fig. 7. SHS Integration Architecture (Conceptual View)

Currently, the service applications are operating

separately without sharing medical and 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:

1.) Data Rewrite

This requires a manual reconciliation of conflicting data

in the data stores, and modifying the associated business

logic to conform to this. This approach is not 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.

2.) 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.

5. Technology Architecture

1.) Evaluation of Technology Architecture

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 the appropriate criterion to

consider in this stage of process.

B.) Evaluation Methods The purpose of selecting IIS 7 and JBoss 6.0 is related

to the suitability of an 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 Framework within the Microsoft

Windows operating environment [10]; while APP operates

in JBoss on a UNIX deployment server, which was

considered to be more suitable in comparison to Jetty,

Apache or Tomcat deployment services [11]. In addition,

the added breadth of operating platforms being used by the

legacy applications require key-subject matter experts to

consider the risks of using particular software technologies

in the final middleware implementation.



60

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 [12],

improves performance (logical queues) and security [13]

(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.

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 conversion between two applications, such as image

conversion of x-ray, ultrasound, computer-assisted

tomography scans and magnetic resonance imaging scans.

Fig. 8. Execution View of the SHS

E.) Technological Constraints The execution of APP on JBoss and 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.

Fig. 9. Deployment View

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.

6. 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:

1.) 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 web services 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 [14]. Data security compliance and extensive traffic

across modules means more performance constraints across

system units. 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 and use of enterprise



61

class technologies need reflection.

2.) 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).

3.) 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 business mandates.

Stateless services allow load-balancing of critical

components using specialized hardware devices.

Non-runtime reliability shall be assured by having all newly

developed modules specifically designed to cater to the

boundary conditions of Initialization, Failure, Recovery and

Termination.

4.) Security

The entire SHS System shall be deemed to be running

within an enterprise-level firewall environment. Core

security is covered from five dimensions: SSO which is on

the Authentication Gateway; Encrypted Data Access within

Business Services; Random Queue number allocation by the

Message Broker; Double Firewall and Instrumentation

Logger for auditing security intrusions. The aims of

enterprise-wide security model are to maintain

confidentiality of users, Integrity of data, access control by

owners, authorization, secure authenticated access and

non-repudiation. A layered architecture is employed with

critical assets in the inner area as proposed the figure below.

Fig. 10. Security Context of the SHS System

7. Migration Planning

The SHS aims to smooth out any incompatibilities by

following a migration plan which aims to address common

issues and challenges faced by enterprise level

amalgamation of applications. These challenges have been

addressed by satisfying the transition attributes of the SHS

system architecture:

Adaptability:

The use of generic components and infrastructure

components for future changes. Standardizing

documentation of APIs and testing specifications

for new modules which could be designed as

plugins or extensions. The publishing of new

service modules could be tightly governed by an

enterprise governance-compliant certification

application and signing program.

Simplicity:

The proposed architecture uses the minimum

number of components in the simplest possible

way or least complex design; the encapsulation of

business logic which is health industry specific

should be made to be configurable for easy

transition through and beyond changing

government regulations on data security, privacy

and consumer protection.

Flexibility:

The modular architecture proposed can be

recombined, enhanced, and scaled-out in a variety

of manners, giving flexibility at deployment and

maintenance phases of the development cycle;

Modularity:

The use of layers, components, and modular

techniques aid in a highly robust internal structure,

enhancing overall system reusability; the idea of

pluggable modules which interconnect and harness

upon under-utilized system resources for unified



62

service delivery. A qualified example is the hybrid

VOIP messaging system where data sharing is a

plugin with voice and conferencing capabilities.

Consistency:

The consistent use of the underlying philosophy

behind designing the component responsibilities

and interfaces, and special attention being given

towards achieving a final list of similarly-sized

components to enhance reusability with overall

aesthetics of the proposed architecture; The

compliance to health standards such as HL7 [15] or

government controlled reporting practices are to be

clearly reflected by designing modules which

mimic Clinical records communication in

prescribed format and layout. The perspective of

consistency is not merely confined to data [16], but

applies to system behavior and responsiveness to

new extensions/modules in a predictably accurate

flow.

Orthogonality:

The clear-cut responsibilities of the various

components without overlap, aids in the

orthogonality of the components within the overall

system boundary. As an example, in the health

system one of problems is excessive paper work

for routine clinical tests of same individual and the

missing carry-forward of information with clarity.

The SHS design aims to rectify such anomalies

through notification alerts which allow

administrators to minimize potential data

duplication between modules [16].

A strategic part of the migration is risk analysis and

mitigation strategy planning, with common risks including

bottlenecks in the service bus (i.e. frequent congestion of

the message router), inconsistent entity-mappings in

databases and insufficient monitoring, auditing and logging

mechanisms for troubleshooting. The system architecture

should quantify the technical benchmarks based on current

statistics to better guide the priorities during development

process for migration.

8. Implementation Governance

Implementation governance is a significant aspect of

architecture governance, which covers the management and

control of all aspects of the development and evolution of

enterprise architectures and other architectures within an

enterprise [6]. To aid the process effective use of tools such

as online code repositories, build management, ticket

management, testing and code reviews management which

are an enabler to provide transparency over the

implementation process where architects can assess the

project on demand.

This is a crucial phase which forms an Architectural

Contract between the architecting organization and the

sponsor of the enterprise architecture. It is intended to assist

in identifying effective processes and organizational

structures. This is to ensure that the complete set of business

responsibilities associated with architecture governance can

be clarified, communicated, and managed effectively by all

stakeholders of SHS [1]:

Implementing Control:

Cover the creation and monitoring of all

architectural components and activities, to ensure

the effective introduction, implementation, and

evolution of architectures within the organization;

Ensuring Compliance:

A system to ensure compliance with internal and

external standards and regulatory obligations. This

is a quality and reliability indicator for the final

build of the SHS system;

Establishing Management:

Processes that support effective management of the

above processes within agreed parameters of the

health institution;

Ensuring Accountability:

Developing practices that ensure accountability to

a clearly identified stakeholder community, both

inside and outside the organization.

9. Architecture Change Management

The objective of the final phase is to establish an

architecture change management process for the new

enterprise architecture baseline. This process provides for

the continual monitoring of such things as new

developments in technology and changes in the business

environment (in the scope of health practice), and for

determining whether to formally initiate a new architecture

evolution cycle [17]. Some of the key inclusions in the SHS

change control sheet considered important by the authors, as

part of the internal quality review process emphasized by

TOGAF [1] are as follows:

1.) Change Request

This includes the following details: Originator

Information; Items to be Changed; Description; Cost

Estimate, Priority, Constraints, Implications, Risks and

Version Upgrades.

2.) Change Evaluation

This includes consideration of the request based on

what components are affected, related changes, work

required, criterion listings and budgetary impacts.

3.) Change Implementation

This contains the architectural adjustments required

and/or approved, technological changes including new

component introductions, and timeline information.

The key challenge is to keep all systems current with

advancement of new extensions, developments, data sets,

perspectives and interfaces as to deliver a robust health

system infrastructure.



63

4.) Key Performance Indicators

The qualitative evaluation and merits of the SHS

architectural transition was performed using the

Architectural Tradeoff Analysis Method (ATAM) as

defined by the Software Engineering Institute of Carnegie

Mellon University [2]. The assessment criterion was

specified according to the migration planning transition

attributes in Section 7 of this paper:

TABLE 1:

ATAM ASSESSMENT OF SHS VS. LEGACY ARCHITECTURE

Legacy PIMS and APP

Architecture

SHS Integrated Enterprise

Architecture

Quality Attribute Rank Quality Attribute Rank

Adaptability Legacy applications built

on different platforms

(Java and .NET), no interconnectivity between

components

6/10 Adaptability Integration platform

integration using W3C Web

Service Platform for standard interconnectivity between

subsystems

9/10

Simplicity Two separate business

logic components have

separate login/sign-on functionality for each

subsystem to authenticate

users

5/10 Simplicity Unified architecture provides

single sign-on (SSO) feature

to allow global accessibility to functions, thus reducing 2

sign-on panels to 1 SSO

(50% reduction in login)

8/10

Flexibility

Legacy applications run

separate database subsystem for persistence

of health and staff records

5/10 Flexibility

Integrated architecture

utilizes a Enterprise Data Integration Service (EDIS)

database with failover,

reducing data duplication from 2 to 1 database (50%)

8/10

Modularity

Each legacy application has been designed

according to their own

architectural and end user specifications

5/10 Modularity

SHS Architecture has been designed using a unified

Enterprise Service Bus

(ESB), unifying external client, management and staff

users

7/10

Consistency Legacy applications apply

different design software

patterns for implementation, each

compliant to their relevant

specifications

6/10 Consistency The core architecture

integrates an ESB with

business orchestration rule-sets, ensuring that all

legacy and future services are

compliant according to HL7 reporting standards

8/10

Orthogonality

Each legacy application

has been designed with their own core

responsibilities in mind

6/10 Orthogonality

Integrated architecture

prevents overlap of business responsibilities through a

unified authentication system

(SSO) and database (EDIS)

8/10

Architecture Summary

Each subsystem runs

independent of each other

33/60 Architecture Summary

Integrated platform unifies

legacy and new services together for extensibility

48/60

10. Conclusion

The SHS System meets the health industry’s need for

consolidated patient records through the use of TOGAF by

reducing the need for rework on legacy applications to fit

into the new unified framework. This is achieved by

investigating the candidate architecture models, frameworks

and patterns that match the category of integration

facilitators, to ensure the health institution’s demands for

scalability and extensibility is realized. The framework’s

architectural development method is effective in assessing

the failure in services delivery in health industry and

provided new perspectives to better define system

requirements from various stakeholder perspectives,

inclusive of health professionals and administrators. It also

provides an efficient transition of the system from legacy

applications to its eventual role as a comprehensive health

administration application for universal patient recording.

The final SHS architecture satisfies the business case

requirements by allowing legacy systems to be interfaced

with additional features that are robust, secure and meet

regulatory standards.

Acknowledgements

Richard Raban (PhD), Rajesh Shenoy and Sepehr

Madavi from the UTS Faculty of Engineering and IT are

acknowledged for their assistance in the SHS Project.

References

[1] TOGAF Version 9.0 Enterprise Edition, website:

www.opengroup.org/togaf/, last viewed 15/11/2009

[2] www.sei.cmu.edu/architecture/tools/atam/ Software

Architecture Analysis Methodologies, Software Engineering

Institute, Carnegie Mellon University, Last viewed 3/4/2011

[3] J.A. Zachman, "A Framework for Information Systems

integration framework," (1987) IBM Systems Journal, Vol 26,

No 3, IBM Publications

[4] Federal Enterprise Architecture Model, Website:

http://www.whitehouse.gov/omb/e-gov/fea/, Last Viewed

4/04/2011

[5] C. Szyperski, Emerging Component Software Technologies,

Strategic Comparison, Software Concepts & Tools, Vol 19, No

1, pp. 2-10, 1998

[6] R. Sessions, (2007), A Comparison of the Top Four

Enterprise-Architecture Methodologies, Website:

msdn.microsoft.com/en-us/library/bb466232.aspx, Last

Viewed 11/05/2011

[7] B. Moulton, Z. Chaczko, & M. Karatovic, "Updating

Electronic Health Records with Information from Sensor

Systems," (2009) Journal of Convergence Information

Technology Vol. 4, No. 4.

[8] E. Freeman & D. Gelernter, "Lifestreams: A Storage Model for

Personal Data," (1996) SIGMOD Record, vol. 25, no. 1, pp.

80-86

[9] U. Wilensky & M. Resnick, New thinking for new sciences:

immediate role of an application integration framework for

Constructionist approaches, San Francisco Press, CA, 2005

[10] Microsoft Corporation, Application Architecture for .NET:

Designing Applications & Services, Website:



64

msdn.microsoft.com/en-us/library/ms954595.aspx, Last

viewed 4/11/2009

[11] M. Fisher, R. Lai, S. Sharma, & L. Moroney, Java EE and

.NET Interoperability, Integration strategies, patterns and Best

Practices, Prentice Hall, Sun Microsystems Press, 2006

[12] L. Bass, P. Clements, & R. Kazman, Software Architecture

in Practice, Addison-Wesley Longman Publishing Co., Inc,

1998

[13] L. Dobrica & E. Niemela, "A Survey on Software

Architecture Analysis," (2002) IEEE Transactions on Software

Engineering, vol. 28, no. 7, pp. 638-653

[14] P. Kruchten, H. Obbink, & J. Stafford, The Past, Present

and Future of Software Architecture, IEEE Software,

March-April 2006

[15] Health Level Seven International Standards, Website:

http://www.hl7.org/, Last Viewed 3/05/2011

[16] C. Britton & P. Bye, IT Architecture and Middleware,

Strategies for Building Large Integrated Systems, 2nd Edition,

Addison-Wesley, 2004

[17] M. Rosen, B. Lubinky, K.T. Smith, & M.J. Bacle, Applied

SOA, Service-Oriented Architecture and Design Patterns,

Wiley Publishing, 2008

Christopher Chiu is a PhD Research

Candidate at the University of

Technology, Sydney. His experience

in agent-based software architectures

lead to his research interests into Java

agent technologies in Sensor Actuator

Networks for the medical health

sector.

Avtar Singh Kohli is a Software

Engineering and Finance Graduate at

the University of Technology, Sydney.

His industrial expertise in enterprise

web application development has led

to his continued interest in

middleware technologies and

applications for health and business

enterprise domains.

Zenon Chaczko (PhD) is ICT Group

Head for the University of Technology,

Sydney. His domain knowledge in

biomimetic software architecture and

middleware, software engineering

project management and object

oriented design and technology has led

to his best paper award in CASYS

2009 for Anticipatory Biomimetic Middleware.

Documents

Building an Intelligent Health System Using an Evolutionary Architectural Model of Middleware