Migrating Healthcare Applications to the Cloud through Containerization and Service Brokering

Organizations that are building their own cloud infrastructure from scratch or rely uniquely only on an infrastructure as a service (IaaS) from a provider, risk spending valuable resources and time building a specialized platform instead of focusing on their core business. On the other hand, organizations who adopt a turnkey proprietary cloud stack will lack flexibility and may end up locked into a specific technology or vendor.

Instead of designing the cloud architecture from the bottom up or the top down, a better strategy is to design from the inside out. By starting with the platform as a service (PaaS) as the central critical layer and creating ways to use various IaaS models and offerings in generic ways, it is possible to create a flexible and efficient lifecycle for the services and applications running on the platform.

In Healthcare, PaaS technology such as the one offered by Pivotal Cloud Foundry facilitates the rapid creation and migration of existing applications towards better user engagement, increasing collaboration between care givers and improving the lives of patients, while reducing the total cost of ownership (TCO).

The main characteristics of this platform are:

• Application containerization
• Optimized application scaling
• Application to service brokering
• Abstraction of IaaS
• Excellent application lifecycle management
• Automatic middleware stack and operating system configuration
• Advanced application monitoring

In this architecture, backing services (e.g., databases, caching systems, other data services (e.g., Amazon S3), messaging/queueing systems, SMTP services, various external APIs (Google Maps, terminology services, healthcare registry services) are just attached resources. For example, there is a distinction between a local digital imaging and communications in medicine (DICOM) local image store and a remote, 3rd party DICOM picture archiving and communication system (PACS) service hosted in the cloud.

The type of platform is especially suitable managing micro services, which allows better componentization, development and testing processes, decentralized governance, resilience and maintainability. These services, especially when they are based on a RESTful architecture, are extremely easy to build, integrate, test, extend, and maintain, and are extremely adapted for mobile applications integration.

Good and efficient lifecycle management is important to produce and maintain high quality software. This is particularly important in healthcare where the patient life is at risk or a breach of privacy could occur as a result of poor quality software.

The advantage of abstracting the IaaS layer access through a common API is that there no need to have multiple versions of application code for each deployment model. The same code will work and be monitored the same way for all cloud deployment models, including on premise and hybrid.

On top of the generic open PaaS infrastructure, we are adding generic and cross-cutting capabilities not part of the original platform including:

• Identity management to allow customers, patients and consumers to be accurately and uniquely recognized by using an enterprise master patient index (eMPI) for patients and a lightweight directory access protocol (LDAP) based directory for healthcare providers and consumers.
• Security/Identity Access Management: authentication, authorization, and single sign-on, all critical to secure provider, patient, and consumer applications and in certain cases, can be addressed by declarative proxification of these services.
• Cloud-based, connected device management: device registration, discovery, routing, diagnostics, remote control, firmware provisioning, data collection, device-app-user pairing (we are currently supporting 6 million active consumer devices).
• Open cloud based clinical workflow collaboration capabilities.
• Secure cloud-based big data store and analytics capability (e.g., to store patient’s observations and genomic data.

  

We are also creating and exposing healthcare and wellness related services that applications can consume:

• IHE-based demographic, clinical, providers web services (e.g., PIX/PDQ, XDS, HPD)
• A virtual longitudinal healthcare record (VHR) and associated services
   - ATNA-based auditing services
   - Consent and delegation services

Our HealthSuite Digital platform also offers high availability, scalability, privacy and security compliance with regulations (e.g., HIPAA, HITECH) and standards (e.g., NIST SP800-53, ISO 27001) using multitenancy, redundancy, 24/7 monitoring and operations, and disaster recovery.

   More on:  F. Andry, R. Ridolfo, J. Huffman, Migrating Healthcare Applications to the Cloud through Containerization and Service Brokering, 8th International Conference on Health Informatics (HealthINF 2015), pp. 164-171, Lisbon, Portugal, January 2015.

Combining IHE transactions : Orchestration or Choreography?

Integrating the Healthcare Enterprise (IHE) has gained tremendous momentum in the past few years. Started as a Healthcare Information and Management Systems Society (HIMSS) and Radiological Society of North America (RSNA) workshop in October 1998 with only 15 participants including AGFA, Cerner, Fuji, GE, HP, Philips, Siemens, the IHE initiative has more than 400 members worldwide. It is composed of healthcare professional associations, government agencies, Health Information Exchanges (HIE), healthcare providers, IT and consulting companies, trade, educational, standard and research organizations. IHE provides a standards based-interoperable framework to share and exchange information between healthcare organizations across networks.

Combined with the latest technology and well established standards (HL7, DICOM, IDC9/10, LOINC, W3C), clinical data can then be securely and privately accessed and transmitted locally between network endpoints (e.g. within the same hospital between the practices and a lab). IHE profiles can also be used across Health Information Exchanges (HIE) of Regional Health Information Organization (RHIO), or a state level (e.g. an individual state in the US, Canada or Europe), or at the federal level (e.g. the US Nationwide Health Information Network or NwHIN). As a result, there is a strong need to integrate and combine individual IHE profiles end-points to form “hub of hubs” or “network of networks” to support health information exchange between the participating nodes entities.

Because IHE transactions are most likely to be offered as web services, combining those transactions can be done following Service Oriented Architecture (SOA) and Service Oriented Computing (SOC) principles.

Conventional middleware distributed system infrastructures (e.g. JMS) are generally not sufficient or flexible enough to mediate, transform, federate and route messages from and to web services.

Enterprise Application Integration (EAI) goes one step ahead, trying to separate the applications from the web services end-points. EAI usually employs a centralize service broker for this, a set of connectors and an independent data model. Services can then send and subscribe to receive messages to and from the broker. However, this very centralized approach requires a large amount of up front development and business process design for the connectors, as well as high cost of maintenance in general. Enterprise Service Buses (ESB) is an infrastructure that leverages EAI principles.


Orchestration

Like EAI, orchestration uses a centralized approach. Web services orchestration is realized through Business Process Execution Language (BPEL) that describe the collaboration and interaction between the web service participants.

Business workflows, states, actions, events, control flows and exception handling can be specified. Messages can be received and sent directly from and to WSDL ports. Results received asynchronously from web services can be combined to create new messages. Usually BPEL workflows are created and updated with visual design tools.

There is often an overlap between orchestration engines and Enterprise Services Buses (ESB). Vendors now also offer BPEL design on top of more generic EAI mechanisms enabling true orchestration for ESBs.


Choreography

Choreography is more distributed and collaborative in nature and uses the Web Service Choreography Interface (WSCI) specification and the WSDL description files to represent the flow of messages exchanged between the Web services involved.

Choreography seems more flexible than orchestration since it does not rely on a central element that could become a bottle neck and seems to offer more complex interaction potential between web services. However, choreography has some drawbacks including the necessity for all web services to be aware of overall business process workflow. WSCI itself does not specify the definition and the implementation of the mechanism to implement the message exchange.

In addition to this, performance can be an issue if high volume message transactions between the end-points peers are not handled properly.

Moreover, there is no clear responsibility for the overall workflow leading to legal issues related to monitoring and maintenance.


Orchestration vs Choreography

Orchestration also has the advantage to be a much more mature integration technology than choreography. For these reasons, most of the state-wide health information exchange networks in the US employ a Service-Oriented Architectural (SOA) model that is implemented through an Enterprise Service Bus (ESB) orchestration.

In addition to this, web service orchestration offers much more than just technical benefits:

• Organizational: standardization, narrow gap between business analysts and developers;
• Managerial: risk reduction, lower costs, more flexibility;
• Strategic: IT resilience, delivery time reduction, less technology lock-in;
• Technical: portability, reuse, interoperability of tools, less complex code, better maintainability;
• Operational: efficiency, automation, higher level tasks management.

When deployed on high performance platforms such as SOA software appliances, orchestration solutions are easy to test, extend and maintain.

• More on this topic to be published as part of the following paper: Andry F., Wan L., HEALTH INFORMATION EXCHANGE NETWORK INTEROPERABILITY THROUGH IHE TRANSACTIONS ORCHESTRATION, 5th International Conference on Health Informatics (HEALTHINF 2012).