A PORTAL FRAMEWORK ARCHITECTURE FOR BUILDING

HEALTHCARE WEB-BASED APPLICATIONS

Francois Andry, Erik-Paul Gibson, Goutham Naval, Thomas Odenwald, Ben Vigil, Frank Yu

InterComponentWare Inc., 1820 Gateway Drive - Suite 300, San Mateo, CA 94404, U.S.A

Karsten Klein

InterComponentWare AG., Industriestraße 41, 69190 Walldorf, Germany

Keywords: Portal, Portlets, SOA, Security, Context Management, PHR, EHR, Care Disease Management,

Personalization.

Abstract: Portals are Web-based applications that give users a centralized point of access for information and

applications of relevance. Therefore the portal paradigm is an attractive proposition for healthcare because it

offers a solution to rapidly aggregate heterogeneous applications and services while offering a high level of

customization and personalization to the users, patients, care givers and IT personnel. In this paper, we

explain the motivations that led us to integrate a portal framework on top of our solution stack to create

healthcare solutions for our partners and customers. We describe the challenges associated with this type of

infrastructure for healthcare applications including security and context management. We present concrete

solutions for specific portal applications integrating EHR, PHR, care and disease management

functionalities.

1 INTRODUCTION

The integration of healthcare systems and data is a

major challenge. Business conditions that typically

result in fragmented data stores and limited

application functionality are prominent in the

healthcare industry (DesRoches et al. 2008), (Ashish

et al. 2009).

While other industries are advancing in SOA

principles, the healthcare industry only recently has

started to embrace the concept of service-oriented

architecture (SOA) as a solution (Sartipi, Yarmand

and Down 2007) to integrate heterogeneous and

legacy systems independently from the underlying

platforms or programming languages. The

healthcare industry is looking for ways to process

data stored in the existing silos and offer useful

healthcare services to assist clinicians in making

rapid and accurate decisions while helping to

prevent medical errors and save costs in the process.

To meet these requirements, we envision newer

healthcare services for providing interactive portals

for payers, providers, collaborative care and for

telemonitoring.

However, because not all healthcare systems are

fully modularized or offer complete external service

layers or APIs, there is a need for ways to integrate

functionalities higher in the software stack, closer to

the presentation layer through an architecture that

enables interoperability and integration (Smith

2004).

To meet these challenges, we have created a

Portal framework architecture which makes the SOA

concept less abstract by offering a concrete service

aggregation infrastructure including integration glue

like context and code mapping, transformations,

master patient index, single sign on and standards

based interfaces. The framework facilitates the

integration of various applications, so they need not

be rewritten to be able to provide services to the

portal. Our portal framework is compliant with

industry standards such as JSR 168, JSR 286 and

WSRP (Hazra 2002).

344

Andry F., Gibson E., Naval G., Odenwald T., Vigil B., Yu F. and Klein K. (2010).

A PORTAL FRAMEWORK ARCHITECTURE FOR BUILDING HEALTHCARE WEB-BASED APPLICATIONS.

In Proceedings of the Third International Conference on Health Informatics, pages 344-349

DOI: 10.5220/0002755303440349

 SciTePress

2 ARCHITECTURE BENEFITS

2.1 Front-end Components Aggregation

Information users often use many different systems

and interfaces. The healthcare industry offers a

typical example of this situation. Healthcare IT

systems tend to be deployed in very specific

contexts, like in departments such as labs, radiology,

ER, surgery. The data generated by these systems is

valuable to a range of users who play very different

roles in the healthcare process. The roles these users

play in their jobs are neither reflected in their

systems of choice nor in a single point of access.

Therefore, the ability to create role-based front-

end interfaces is valuable. Role-based concepts are

included in most portal offerings and offer flexible

configuration capabilities for specific targeted sets

of user groups. This is especially important in the

healthcare industry in the United States where the

market is fragmented and requires a lot of product

customization and re-branding. Aggregated in Web

portals, front-end components can be built on top of

existing data structures, enterprise and legacy

systems as well as third-party services (Deora et al.

2006).

Though, focusing solely on market factors as

drivers for front-end flexibility neglects the

underlying challenge facing healthcare software

developers. Not only are users confronted with

multiple, siloed IT systems, they are also affected by

shifting roles and a convergence of IT services made

possible by growing electronic data availability. For

example, physicians have traditionally focused on

diagnosis and treatment, rather than prevention. But

external forces like healthcare reform, Health

Information Exchanges (HIE) and Pay for

Performance (P4P) initiatives are shifting physicians'

concerns. Fortunately, as physicians change their

approach to healthcare new technologies, data and

tools are emerging to aid this transition. These same

tools also lead to expanded roles for other care

givers and a greater opportunity for collaborative

care.

This constant flux of user role definitions and

changing use cases requires exceptionally agile

development. Rapid prototyping and constant

acceptance testing are critical to solving the business

challenges of the healthcare industry. The additional

development flexibility afforded by portals enables

software companies to react more quickly to the

market and to customers needs.

Software portal containers can help software

companies break large software projects down into

smaller more manageable pieces usually referred to

as modules. Such modules can be visualized by

portlets, which can be designed and developed

separately and deployed as they are completed. As a

result, vendors can more quickly develop features

and functions as needed by their customers and

demanded by the marketplace.

2.2 Portal Characteristics

An enterprise horizontal portal is the delivery layer

for a heterogeneous environment (potentially in

healthcare, the complete continuum of care). It

usually includes the following features:

 Single Point of Entry: Portal solutions offer a

unified and personalized view for various

healthcare professionals (Koufi et al. 2008),

and provide real-time access to a selected

patients’ clinical information with integrated

single sign-on (SSO) authentication

capabilities;

 Permissions: the ability for portal

administrators to limit specific types of

content and services to groups of users based

on their respective roles and profiles;

 Integration: the aggregation of data and

services from multiple systems including

generic content, knowledge management and

collaboration components into visual front-

end fragments or portlets;

 Federation: the combination of content from

various sources;

 Enhanced User Experience: an efficient and

consistent user interface (even though the

underlying services can come from multiple

sources);

 Personalization: the ability for users to

choose specific services and content tailored

to their need and to customize the layout and

look and feel of their presentation layer.

2.3 Benefits to the Healthcare IT

Delivery Network

A portal approach can bring benefits to the whole

healthcare IT delivery network:

 Benefits to the End-users: The portal

application represents a single point of access

to perform important healthcare tasks through

a very convenient “dashboard” paradigm.

Portal solutions also present a rich user

experience by leveraging Web 2.0

technologies (Phifer, Gootzit and Valdes

2008) and specific components (e.g. wikis,

A PORTAL FRAMEWORK ARCHITECTURE FOR BUILDING HEALTHCARE WEB-BASED APPLICATIONS

345

blogs, message boards, social networking,

maps etc). Portal customization and

personalization also offers end-users a more

personalized experience based on their

profiles such as their role in the organization

or user group and preferences (e.g. choice of

layout, look and feel, medical content);

 Benefits for the Development Team: This

includes a common architecture for the

aggregation of heterogeneous components and

services, a clear separation between the

presentation layer and the service layer, and

the fact that portlets are based on standard

technologies (e.g. JSP. JSF, Spring, Hibernate,

JSR 168, JSR 286, WSRP, AJAX, Java EE, or

even Adobe Flex). We have also developed

reusable GUI components using JSF

framework and portlet templates;

 Benefits for the Professional Service Team:

Portal technology can save substantial costs to

the professional service team tasked with

creating solutions. A portal approach that

includes the ability to create and combine

customized components that are easily

customizable and re-branded for customers

offers a good return on investment (ROI);

 Reduce TCO (Total Cost of Ownership):

For the healthcare IT departments deploying

and maintaining services and applications, the

ability to run multiple portal sites, each with a

unique domain, on the same portal server

reduces the duplication of hardware and image

instances. Portlets can be deployed at run-time

(hot deployment) reducing down time for the

user, facilitating the maintenance of the

applications and increasing the overall quality

of service (QoS). In addition, specific content,

branding, layout and skins can be stored and

managed independently of the application in a

content management system, saving costs

during deployment and maintenance.

2.4 Standardization Benefits

Over the years there have been a lot of

standardization efforts (HL7, ISO, Continua, HITSP,

IHE) in the healthcare industry, especially in the

area of interoperability. Horizontal enterprise portals

can take advantage of these standards as a safe and

reliable means to communicate between the different

healthcare systems.

Horizontal enterprise portal servers themselves

have been used successfully for more than a decade

in various fields. As a result open source solutions

and standards have emerged (JSR 168/286, WSRP

that can be leveraged for healthcare portal

applications as well (Gootzit and Valdes 2008).

These standards define the basic behaviors of the

container, the lifecycle management of the portlets,

security, coordination between portlets,

communication protocol between a portal

application and remote portlets, packaging and

deployment of portal applications.

2.5 Enriching the Existing Standards

JSR 168 & JSR 286 standards are useful for building

relatively simple portlets. However, because today’s

users have come to expect responsive and fluid

interactions in Web based applications, the basic call

and response model of the portal server (including

systematic refresh of whole Web pages) is not

sufficient.

Popular Rich Internet Application (RIA)

technologies include AJAX (Asynchronous

JavaScript and XML), Adobe ActionScript/Flex and

Microsoft Silverlight. These technologies, which are

not part of the JSR portlet specifications, need to be

combined with portal frameworks to create modern,

interactive Graphic User Interfaces (GUI).

The solution is to build the basic functionality

based on the JSR portlet standards and then extend

the user interfaces using more advanced RIA

technologies (Phifer, Gootzit and Valdes 208). This

will allow for easy (but not seamless) portability

between popular portal containers while delivering a

modern user experience.

3 FRAMEWORK USE CASES

For the past couple of years we have collected

requirements for Healthcare Web Applications from

a number of sources: requests for information (RFI),

requests for proposals (RFP) and direct discussions

with our customers. In these requirements, portal

architecture is mentioned more and more frequently

because portals are viewed as a solution to some of

the fundamental healthcare IT challenges—siloed

systems as well as the convergence of healthcare

services.

Table 1: Requests for proposal with portal requirements.

Request for Proposals Date

Texas Medicaid Administrative

Claiming (MAC)

2009

Kentuky Health Information Exchange 2009

Ontario Diabetes Registry 2008

HEALTHINF 2010 - International Conference on Health Informatics

346

In Texas, stakeholders see portals as a solution to the

traditional problem of merging data from disparate

systems to provide an aggregate view into a patient's

status. Both Kentucky and Ontario are looking to

solve similar challenges, but they are also using the

unification of data as a driver to expand available

healthcare IT services.

For example, in the recent Ontario Diabetes

Registry RFI, the portal application includes

electronic medical record (EMR) functionalities as

well as other services like real-time vital signs

(through device integration), e-Prescribing, doctor to

patient communication, clinical guidelines, alerts

and task management. The goal of this project is not

only to solve the problem of decentralized data, but

also to support the possibilities that IT holds for

advancing healthcare delivery.

4 ARCHITECTURE DETAILS

4.1 Front-end Aggregation Layer

Our product suite was developed according to a

specific set of use cases with particular user profiles.

What we discovered through market research that

features that were intended to be consumed by a

particular user actually had relevance to other users

in the care process.

To address this type of requirement, we had to

integrate some of our existing products (Andry et al.

2008), (Andry et al. 2009) such as our Personal

Health Record solution, our Professional Exchange

Suite (PXS) in the form of our EHR (Electronic

Health Record) and CDM (Care and Disease

Management) solution, as well as third-party

components. Some components are directly

integrated at the service layer through our

integration platform (IPF) that is part of our eHealth

Framework (eHF).

The visual components (portlets) are integrated

in a lightweight front-end layer “Fig. 2”, which in

our case is a horizontal enterprise portal framework

layer. Alternative architectures include widgets/

gadgets based portals (Gootzit and Valdes 2008),

(Gootzit 2008) and mashup frameworks.

4.2 Context Management Layer

In addition to the front-end aggregation layer, a

context management layer which uses a subset of the

concepts of the HL7 Clinical Context Object

Workgroup (CCOW) standard (centralized scheme,

robust push-model, simplified context data

representation) is used to solve user mapping and

facilitate the coordination and synchronization

between visual components (portlets in our case).

This context management layer connects to the Web

services (SOAP or RESTfull) that are exposed by

the different products or in certain cases a software

development kit (SDK) which encapsulates the Web

services in functions (java or .NET) that are easier to

use.

Table 2: Components of an EHR Light Portal.

Service/portlet Product/provider

Patient Finder PXS

Patient Demographic Data PXS

Patient Medical Record PXS

Task List CDM

Medical observations LS

E-prescribing 3rd party

Figure 1: ICW Health Portal Framework Architecture.

4.2.1 Sessions and Contexts

A portal application like any other web application

works with a session. All requests are executed in

the context of such session. The session is associated

with an authentication context and a lot of other

information that is accumulated while processing the

requests that are executed with the session. A

session can be understood as a temporary storage

with a well-defined life cycle. A session is ended

either explicitly (log out, connection closing) or by a

time-out.

In the meta-model below (Fig. 2), we describe

the basic relationship between the sessions and other

relevant information.

When accessing the web application for the first

time there is no session established yet. The user is

forced to log in (providing his identity and the

credentials to prove the identity). This establishes an

authentication context which is kept within a

dedicated session. During the requests executed in a

A PORTAL FRAMEWORK ARCHITECTURE FOR BUILDING HEALTHCARE WEB-BASED APPLICATIONS

347

Figure 2: Meta-model connecting session and context

objects.

session, information is accumulated and processed in

the session. This kind of information is generalized

as data context with different specializations such as

context information for patient or any other

healthcare domain objects.

5 DEPLOYMENT SCENARIO

5.1 Simple Portlet Integration

In the most simple deployment use case (see fig.3)

the portal framework is used to create and deploy a

portlet (e.g. a medicine cabinet) that is hosted in a

portal container (A). The portlet uses a proxy

module that has access to remote eHF-based

Application (B) including the Medicine Cabinet

Service Module, which exposes the required web

remote interface (e.g. a RESTful web service).

Figure 3: Portal deployment use case.

5.2 Connecting the Services

Both the portal application (A) and the remote

system (B) may have their own identity management

capabilities and their own credential storage. In

order to integrate A and B we have implemented an

extended SAML based token service. The resulting

Security Token Service (STS) service includes the

token service module as well as an eHF based

context management module. This eHF Context

Module stores the mapping information between

user identifiers from A and the identities of B as

described in Figure 2.

The token service toolkit provides utilities to create,

renew and request tokens. In particular it is possible

to request a token for B based on a token from A.

The resulting token B must of course include a

mapped user identifier and assertions valid for B.

5.3 More complex Scenarios

In reality, portal applications typically consist of

multiple portlets that interact together. Each portlet

can themselves aggregate services from various

sources. This is where the portlet proxy is very

handy because it can shield the presentation layer

from back-end service implementation details.

The integration of a new application exposing

web services (SOAP or RESTful) is made easier

because eHF provides a mediation and routing

platform component (IPF) based on Apache Camel

that can wrap these services, operate transformations

on data and expose them to the portlet proxies. In

addition to this the current use of the Security Token

Service for authentication can be complemented by

the use of a Single Sign On (SSO) mechanism.

6 CONCLUSIONS

Our portal framework architecture provides

healthcare application developers a set of open

source components based on standards, tools,

methods and processes to create more complex

integrated and context-aware portal applications

covering the full continuum of care for professional

care givers and patients. Our framework offers high

security, privacy, performance and scalability

compliant with government regulations such as

HIPAA.

In the next milestones of this project we will

focus on portal usability, inter-portlet

communication, quality assurance and lifecycle best

practices, providing the users of our framework

guidelines, blueprints and sample healthcare portlets,

themes, content, as well as business perspective

material (licensing, support and revenue models)

related to the use of the framework.

ACKNOWLEDGEMENTS

We are extremely grateful to John Gillson, Liliya

Gor¸ Juergen Groothues, Andreas Kaltenbach, Igor

HEALTHINF 2010 - International Conference on Health Informatics

348

Kosoy, Salim Kizaraly, Lucy Lin, Dimiter Makariev

and Dirk Wippermueller for their help. Thank you

also to Rostislav Georgiev and the UICC team for

their JSF/UI library contribution. Our appreciation to

Richard Golden, Matthias Laux, Thomas Liebscher

and the ICW architecture board members for their

feedback on this project.

REFERENCES

Andry, L. Freeman, Gillson J., Kienitz K., Lee M., Naval

G., Nicholson D., 2008, “Highly-Interactive and User-

Friendly Web Application for People with Diabetes”,

IEEE 10th International Conference on e-Health

Networking, Application & Services (HealthCom 08),

pp. 118-120, Singapore, July 2008.

Andry F., Naval G., Nicholson D., Lee M., Kosoy I. and

Puzankov L., 2009, “Data Visualization in a Personal

Health Record Using Rich Internet Application

Graphic Components”, 2nd International Conference

on Health Informatics (HealthINF 09), pp. 111-116,

Porto, January 2009.

Ashish K. et al., "Use of Electronic Health Records in U.S.

Hospitals", The New England Journal of Medicine,

Volume 360:1628-1638, Number 16, April 2009.

Deora V., Contes A., Rana O., Rajbhandari S., Wootten

L., Tamas T. and Varga L., 2006, “Navigating

Provenance Information for Distributed Healthcare

Management”, IEEE/WIC/ACM International

Conference on Web Intelligence, 2006, pp. 859-865.

DesRoches C. et al., 2008, "Electronic Health Records in

Ambulatory Care — A National Survey of Physicians",

The New England Journal of Medicine, Volume

359:50-60, Number 1, July 2008.

Gootzit D., 2008, “Second-Generation Portlet Standards

Should Be Used for Portlet Development but Aren't the

Whole Story”, Gartner Reports, ID Number:

G00163990, December 2008.

Gootzit D., Valdes R., 2008, “Open Source and Portals”,

Gartner Reports, ID Number: G00156161, April 2008.

Gootzit D., 2009, “Get Ready for the ‘Portal-Less’ Portal,

Gartner Reports”, ID Number: G00166378, March

2009.

Hazra T., 2002, “Building Enterprise Portals: Principles

to Practice”, Proceedings of the 24th International

Conference on Software Engineering, pp. 623-633,

Orlando, Florida, 2002.

Koufi V., Malamateniou F. and Vassilacopoulos G., 2008,

“A Medical Diagnostic and Treatment Advice System

for the Provision of Home Care” Proceedings of the

1st international conference on Pervasive

Technologies Related to Assistive Environments -

PETRA'08, July 15-19, 2008, Athens, Greece.

eHF - eHealth Framework, http://idn.icw-global.com/.

Phifer G., Gootzit D., Valdes R., 2008, “Generation Six

Portal Products: When Portals Meet Web 2.0, It's

Love at First Sight” Gartner Reports, ID Number:

G00166723, March 2008.

Sartipi K., Yarmand M., and Down D., 2007, “Mined-

knowledge and Decision Support Services in

Electronic Health” International Workshop on

Systems Development in SOA Environments

(SDSOA'07), 2007.

Smith M., “Portals: Towards an Application Framework

for Interoperability”. Communications of the ACM,

Volume 47, Issue 10, 2004, pp. 93-97.

A PORTAL FRAMEWORK ARCHITECTURE FOR BUILDING HEALTHCARE WEB-BASED APPLICATIONS

349