REST-Style Architecture and the Development of Mobile Health Care Applications

Mobile devices offer new ways for users to access health care data and services in a secure and user-friendly environment. These new applications must be easy to create, deploy, test and maintain, and they must rely on a scalable and easily integrated infrastructure.

In the ambulatory health care environment, providers spend the majority of their time in an examination room with patients. Although some clinics have installed personal computers in the exam room for use at the point of care, many physician practices have yet to do so or have no such intention. Reasons for not installing PCs in the exam room include (among others) lack of space, security concerns, and cost. Often, clinics have PCs installed outside of the exam room to be used for encounter documentation or health history research (i.e., reviewing the patient's health records). This physical setup is often satisfactory for providers to complete their documentation needs. Providers often scratch rough notes on paper during an encounter, then dictate or type their notes after the visit has ended. The absence of computers in the exam room, however, is a disadvantage for research activities. Frequently, after listening to the patient's verbal health history, a provider wishes to read past records. If those records are in an electronic format, it is optimal to access those records at the point of care (i.e., in the exam room).

Thus, computer devices that are smaller and more mobile than a PC (e.g., smart phones, PDAs, tablets) would be the optimal hardware choice to access these electronic records. Given that many physicians carry smart phones, such mobile devices would be the ultimate tools to look up patient records.

Since the development of client applications on different mobile platforms requires more time than creating web applications for a handful of browsers, it is important to minimize the complexity of the integration with the back-end services and legacy systems and to try to decouple the development and maintenance of the client- and server-side components.

The Representational State Transfer (REST) architecture is an alternative to SOAP and offers clear advantages over SOAP including lightweight architecture, extensibility, scalability, easy of development, testing, deployment and maintenance.

REST API prototypes can be created in a matter of days and a full functioning set of sophisticated clinical based web services accessible by mobile client applications within few weeks.

In addition to this, REST APIs are particularly suitable for fast and loosely-coupled solution integration such as mobile applications, but can also be used in health care for portal and mash-up applications as well.


Reference:
Andry F., Wan L., Nicholson D., A mobile application accessing patients' health records through a REST API, 4th International Conference on Health Informatics (HEALTHINF 2011), pp 27-32, Rome 2011.

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