img > Issue XXVII: March 2009 > SOA in Healthcare - Part II
Girish Juneja

Girish Juneja


Girish Juneja is the Director of SOA Products at Intel.

As the co-founder of the SOA infrastructure company Sarvega, Inc., Girish led the engineering and customer services organizations to develop Sarvega's industry leading core XESOS technology and XML networking products.

Girish has held senior technology and management roles at Thomson Financial Services, Verizon, and MCI Telecommunications, with more than fifteen years of experience in the technology industry in engineering, technology strategy, and management roles.


rss  subscribe to this author

Blake Dournaee

Blake Dournaee


Blake Dournaee is currently the Product Manager responsible for Intel SOA products.

As a Product Manager at Sarvega, he was deeply involved in the development of their flagship XML security, routing, and acceleration appliance products

Blake was a specialist in applied cryptography applications at RSA Security and was a frequent speaker at many RSA conferences throughout the US and Europe.

Blake is an established author who wrote the first book on XML Security.


rss  subscribe to this author

Joe Natoli

Joe Natoli


Joe Natoli is a platform architect in the Digital Health Group at Intel.

Responsible for the end-to-end strategy and architecture for new products, Joe also leads the pilot/concept engineering projects.

Joe has held various architecture positions across Intel's business including e-Business integration infrastructure, supply chain ERP, enterprise data warehousing and business intelligence, as well as portal deployments.

He was founding member and architect of the SOA strategy and planning program for Intel IT, which included development of the overall architecture, best practices, training, production, and POC proof points, as well as the financial return models to monitor program success.


rss  subscribe to this author

Steve Birkel

Steve Birkel


Steve Birkel is the Chief Technical Architect for Intel's Information Technology, where he leads development of technical infrastructure strategy and enterprise integration.

He was instrumental in establishing Intel as a leader in Internet e-Business: his team established the technology backbone for Intel's Web presence and e-Customer and e-Supplier capabilities. He has been with Intel for the past thirteen years.


rss  subscribe to this author


SOA in Healthcare - Part II

Published: March 23, 2009 • SOA Magazine Issue XXVII

Abstract: Healthcare organizations today are challenged to manage growing portfolios of systems and applications. The cost of acquiring, integrating, and maintaining these systems is rising, while end-user demands are increasing. Furthermore, evolving clinical requirements need to be continually accommodated along with the required support for revenue cycle and administration business functions. In addition to all these factors, there are increased demands for enabling interoperability between other healthcare organizations to regionally support care delivery. SOA offers system design and management principles in support of the reuse and sharing of system resources across that are potentially very valuable to a typical healthcare organization. This two part article explores how healthcare organizations can leverage shared services to automate multiple business processes and strengthen overall interoperability while reducing the need to synchronize data between isolated systems. This two part article explores how healthcare organizations can leverage shared services...

Guidelines for Applying SOA to a HIN

When using SOA for HIN integration architectures, the cost of integration can be reduced significantly and a sustainable source of value to the community of care can be established. To accomplish this, the service architecture of the HIN must:

  • Simplify and reduce the number of interface points to create data interoperability in the network.
  • Address the architecture, infrastructure, software, and related business services as a cohesive unit.
  • Be deployable within the hospital, lab, pharmacy, and insurance company as well as within the shared HIN network.
  • Support legacy systems, including current and evolving standards in healthcare data representation.
  • Be scalable from small to large scale healthcare organizations in terms of cost, complexity, utility, and adaptability.

The first key benefit that an SOA technique applied to a HIN will provide is to simplify the data interoperability problem. Although there are industry standards for data representation in healthcare, such as HL7, a fundamental problem with those standards is their varied interpretation in software. Therefore, the very first objective for a HIN should be to standardize the software interpretation and therefore implementation of representation and translation of healthcare data on the network. The most cost-effective way to do this is through a standardized set of core business services that represent healthcare data.

As Figure 1 shows, implementing SOA services to manage a standardized implementation of data representations (the "canonical data representation") reduces the number of systems interface points by an order of magnitude. Instead of each participant in the HIN and the HIN data center having to create and sustain an system interface for each participant in the network, all a participant needs to do is transform their systems representation to the one specified by the service, which defines the canonical form for the specific data being exchanged (such as patient, provider, order, referral, and so on).

Figure 1: SOA Integration Architecture

This SOA, canonical-based architecture to systems integration reduces the number and cost of integration points by over 65 percent.

The canonical data representation that the SOA core business service manages establishes:

  • An independent structure from any specific end-point application
  • Independence (separation) of the information architecture and the technical infrastructure upon which it is implemented
  • Precise message definition to assure consistent implementation
  • Visibility into the data that drives business processes
  • Clear definition of unique applications for a particular business transaction

Leveraging services that are built on canonical data representation allows for the HIN network to rely on a standardized software interpretation of data and therefore allows the network to support the shared instantiation and consumption of system functions by all participants of the network. This allows the HIN to provide shared services such as provider registries, medical vocabulary translation, master-person index, and record locator services on behalf of the entire community of care they represent without those services having to be deployed or duplicated in the data center of each organization which participates in the HIN. Figure 2 describes this architecture and some example shared services.

Figure 2: Possible HIN Service Portfolio

Using the enterprise service bus technology described in Chapters 3 and 4, both the HIN data center and each participating organization in the Health Information Network can publish and consume each others services and establish orchestrated workflows to rapidly support new business transactions and interactions among network participants. Additionally, the service container construct on the service bus architecture allows for existing, in-place clinical and administrative systems within a hospital, lab, pharmacy, or insurance organizations to be "fronted" with XML web services and participate in this architecture. This allows for realizing the benefits of SOA in an incremental and iterative fashion thereby leveraging existing technology investments. Figure 3 is a diagram of the service bus architecture.

Figure 3: Service Bus Architecture

As seen in these examples, using SOA techniques can substantially reduce the costs of implementing a HIN in any scale. SOA also delivers features to the community of care as software services that provide a source of ongoing value beyond hosting a simple portal and database of integrated data records on patients.

Extending Electronic Medical Records through SOA

So far in the chapter we have talked quite a bit about how using SOA techniques can improve the integration of healthcare information systems and substantially reduce the cost of doing so; however world-wide the average amount of automated, electronic clinical information is small.

Many healthcare organizations around the world are planning or putting in place Electronic Medical Records (EMR) systems to automate the collection, distribution, and validation of patient medical records. Although such technology has been commercially available for 30 years, the average worldwide adoption of EMRs by clinicians in their day-to-day work is less than 20 percent. Figure 4 summarizes the reasons for this low adoption rate and shows how SOA can help increase EMR adoption.

Figure 4: Barriers to Electronic Medical Record (EMR) system adoption

Using SOA techniques can address many of the issues described in Figure 4 directly

First, many electronic medical record systems are designed to be enterprise-wide applications spanning departments and medical professions. One common side affect of this broad scope are screens with many tabs, data fields, buttons, and other user interface elements that can complicate the training and use for those whose job only requires a fraction of the functionality to complete the task at hand. An SOA-based EMR can readily support many forms of user interface because the core data and business logic functions are loosely coupled from the presentation. Therefore, the ISV developer or potentially even an IT department with sufficient engineering talent could provide specialized user interfaces by department and/or job role without having to duplicate the core processing and data validation of the EMR engine.

Second, since an SOA-based EMR is constructed as a suite of composable software services for data and business rules, workflows can be more readily customized to support individual organizational or departmental needs without having to resort to a "best-of-breed" deployment where individual departments have nearly duplicate application stacks from different vendors since one vendor supports a particular department's workflows incrementally better. Not only does it save the organizations the costs of paying for what is often the same core technology more than once, it also allows for a significant reduction in integration and sustaining costs as a common service infrastructure is reused over and over in the SOA-based EMR.

Finally, as discussed above, the SOA architecture allows for entire functions of an EMR system's or hospital's processes to be outsourced and hosted in a shared data center and consumed as a utility. Examples include the capabilities that can be offered by an SOA-powered HIN such as controlled medical vocabulary translation, master-person index services, patient record locator services, insurance verification, claims processing, and referral management. The key advantage to this is the cost of implementing and sustaining this functionality. More often than not, acquiring software functionality through the outsourced, hosted utility model (sometimes referred to as utility computing or application service provider) can be done for a materially lower overall total cost. This is due to the fact that the cost of servers, data center infrastructure, software licensing, and engineering are spread over many customers rather than being borne by each customer repeatedly, as is the case when the EMR is hosted on an internal data center. When using SOA techniques and technology, a healthcare IT organization can readily integrate internally hosted systems and technology directly alongside outsourced ones. Figure 5 describes this architecture.

Figure 5: Architecture for Integrating Hosted and Outsource Applications

Building a Roadmap for SOA in Healthcare

Implementing an SOA technology platform and associated organizational infrastructure is not something that can be done in a single event. In healthcare, this is especially true as very few organizations have the budget or can take on the operational disruption associated with tearing out and replacing key business systems in any form of wholesale fashion.

Therefore, major administrative, EMR, and ancillary healthcare systems should first be "fronted" with service interfaces that manage highly shared data and nearly universal redundant processing. In healthcare, that involves data regarding patients, providers, orders, and controlled medical vocabulary. Key highly shared functions include things such as a Master-Person Index (establishing a common record identifier across systems for patients and medical personnel), medical vocabulary translation, and verification of patient eligibility for services via their payer policy.

The key for a healthcare organization is to focus on getting a baseline service infrastructure in place that eliminates redundant entry, storage and transformation of their highly shared data across business processes, and those highly shared functions within the organization first and then look to extend their reach into the community of care through Health Information Networks. This is because most healthcare organizations have a complex application landscape internally and when connecting to a HIN will need to address the architecture, technology, and business implications of providing a standardized representation of their organization's data in order to feed it to and receive it from the HIN. Also, when it comes to evaluating where to start with SOA, it is important to focus on departments and business processes where the ratio of risk, cost, and benefit are most favorable. Often the areas of the healthcare business that will derive the most benefit from SOA architecture are those that also derive the most benefit from having quality, reliable and integrated data at the point of care such as emergency, critical care, and surgical departments and their associated patient care business processes.

Given this, the following are key tasks and milestones to pursue as part of a SOA maturity model in healthcare:

  • Early Learning - Pilot the technology and organization shifts to SOA in one department on a targeted set of highly shared data and functions (such as patients, orders, and medical vocabulary in the admissions and order processes in the ER department).
  • Re-engineering - Extend the technology and organization investments to span departments on the highly shared data and functions as articulated above. Focus efforts on getting to organization-wide standards on this highly shared data and processing. Begin planning for HIN integration.
  • Integration - Implement HIN integration into core systems and departments as the roadmap evolves extended service integration into ancillary and administrative systems.
  • Maturity - A healthcare organization reaches a state of maturity when the SOA technology and organizational infrastructure permeates all major business processes, systems, and departments and supports the organizations HIN initiatives. This includes clinical and administrative systems.

As with any SOA adoption program it is critical to start in a focused, targeted area of the business and build a "snowball effect" of results both in technology and business benefit.

Key Industry Challenges for SOA and Tactics to Address those Challenges

In the healthcare industry IT budgets are far smaller than in other industries such as manufacturing or financial services. It is very common to find budgets in the range of 1.5¡V2 percent of revenues, which is a third to a fifth of the IT budget in other industries. This extremely tight budget situation is further compounded by the fact that these dollars not only compete with things such as personnel, service offerings and facility costs, but also other significant technology assets; namely medical devices (like MRIs, infusion pumps, and so on).

This creates a "chicken-and-the-egg" dynamic for creating an SOA adoption roadmap in healthcare. Achieving the over 40-percent sustaining system and integration cost benefits that SOA offers is sorely needed when budgets are this tight, but at the same time how do enough precious dollars get freed up to sufficiently kick-start the Early Learning and Integration phases of the SOA roadmap?

Another key challenge in healthcare is the state of technology of many healthcare IT vendors. It is quite common for EMR, integration broker, and ancillary system technology vendors to still have products in "green-screen," mainframe, and minicomputer monolithic software technology stacks. Only a small set innovators have invested to bring their software architectures and technology stacks up to the n-tier, web-based technology stacks, but at the time of this writing they remain the suppliers with the minority market share and revenue.

The key tactic to address these issues is timing and finding the right project insertion point for your organization. Intercepting the deployment of a new EMR, department ancillary system, or HIN integration project are the hot new work for many organizations and offer enormous business benefit to be implemented using SOA techniques. Through Intel's interaction with many government and private healthcare organizations as well as the ISV community world-wide we anticipate the overall market to be entering the Early Learning phase of SOA in 2007 and progressing to Maturity post-2010 lagging other industries by 3+ years, which is a pace relative to all other forms of technology adoption in this industry segment.


  • The application of SOA in healthcare can substantially reduce the complexity and redundant system processing of clinical information. It can also help to simplify and reduce the cost of participation in community of care health information networks (HINs), and can improve the cost and usability (and therefore reduce the deployment risk, leading to increased adoption) of electronic medical records.
  • SOA can provide a relatively inexpensive way to develop geographically independent and fault tolerant infrastructure, which is more easily upgraded than tightly bound system integrations. Availability can be increased through service redundancy.
  • Proofs of Concept (POCs) can be done with relatively light resource investment, yet can provide a power tool to enlist the support of technologists and executive management.
  • Due to the tight budgets in healthcare information technology, finding the right insertion project will be critical. A new SOA can build upon the momentum associated with a new EMR implementation, HIN project or organizational merger/acquisition--leveraging these inflection points can provide substantial advantage in SOA deployment.
  • As with any SOA adoption program it is important to start small and build on top of incremental success. In healthcare, that means focusing on the most critical business processes where highly shared data is required and in those processes where the timeliness and accuracy are most critical. This can translate to early SOA focus on patient, provider, order, and controlled medical vocabulary data in critical care settings such as ER, ICU, and surgical.


[REF-1] Canada Health Infoways Integration costing - "EHRS Blueprint -> an interoperable EHR framework. Infoway Architecture Update" Canada Health Infoways Solution Architecture Group March 2006.

This article was excerpted from Service Oriented Architecture Demystified: A Pragmatic Approach to SOA for the IT Executive by Girish Juneja, Blake Dournaee, Joe Natoli, and Steve Birkel. Copyright © 2007 Intel Corporation. All rights reserved. No part of this publication may be reproduced, stored in a retrieval system or transmitted in any form or by any means, electronic, mechanical, photocopying, recording, scanning or otherwise, except as permitted under Sections 107 or 108 of the 1976 United States Copyright Act, without either the prior written permission of the Publisher, or authorization through payment of the appropriate per-copy fee to the Copyright Clearance Center, 222 Rosewood Drive, Danvers, MA 01923, (978) 750-8400, fax (978) 750-4744. Requests to the Publisher for permission should be addressed to the Publisher, Intel Press, Intel Corporation, 2111 NE 25 Avenue, JF3-330, Hillsboro, OR 97124-5961. E-Mail: Intel is a registered trademark of Intel Corporation. Other names and brands may be claimed as the property of others.