Wednesday, December 30, 2009

A Portal Framework for HealthCare

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 health care 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.

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.

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.

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

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.

The basic relationship and mechanism between the sessions, identity and context is described as follow: 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 session, information is accumulated and processed in the session.

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.

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.

For this specific implementation we used Liferay 5.2. as portal server container and a medicine cabinet as healthcare related topic and material.

More details can be found in the paper "A Portal Framework Architecture for Building Healthcare Web-Based Applications" published at the 3rd International Conference on Health Informatics (Health Inf 2010).


santosh said...

hi andry,

your blog is very use ful for portal developement,i have somee quen's

Flex using remote object work fine in liferay or not.

i am new to portlet developement can u please provide some examples to download.

if u have any examples please dorward to my mail id

Santosh M

fandry said...

Hi Santosh,

Yes you can use Flex remoting such as BlazeDS to aggregate and orchastrate back-end or legacy services. See previous posts on my blog.

I do plan to post some code in a near future related to these issues.
Stay tune.



fandry said...


BTW, BlazeDS can be used to access SOAP/REST based services but also directly Java objects (it seems that is what you want to do). For the presentation layer you can use a light MVC framework such
as Cairngorm in conjunction with JSR 286 Liferay Portlet wrappers.

Hope this will help.


cameo said...

Great work. I am currently deep in the middle of work very similar. Did u say you have a framework and if so is it an opensource or closed source framework.

Kind regards

fandry said...


In addition to the paper that has been published, you will find additional information related to this framework on ICW IDN, including information related to open source.

You can also look at sourceforge for the routing and mediation part of the framework (IPF).

Hope this will help.


fandry said...


A presentation on IPF can be found here. Here is also the link to the sourceforge project for this part of the framework.


PassionFish said...

thanks for sharing the great insights.

Trying to understand approach on SAML based token service as Liferay comes with OpenSSO, CAS intergration etc..
ie when the portal application from Liferay(A) - and the remote system (B) talks to each other
what are the advantages of SAML based token service - STS over implementing OpenSSO, CAS or OpenID/OAuth

appreciate your comments thanks JG