Hospitals and manufacturers are exploring SOA strategies to integrate disparate departmental patient databases and systems.

The concept of service oriented architecture, or SOA, may not roll off your tongue today, but in the years ahead you are likely to be saying, hearing, and implementing it more and more frequently. Perhaps you already know SOA by one of its older, more pedestrian names, such as Web services, Web apps, or even net-centric systems, which are terms used by Microsoft, IBM, the Department of Defense, and others.

Believe it or not, you have probably already used SOA-based systems without even knowing they are there. For example, the marvelous Google Earth system that can show you close-up views of the gardens, buildings, and streets around the Louvre museum in Paris is a pretty interesting example. That system uses SOA interface software named AJAX to allow you to see static satellite views almost anywhere on the globe, and it even lets you watch a virtual helicopter or car ride showing what the trip from Paris to Versailles would look like from your front window.

The primary building blocks of SOA are shown in Figure 1. At its roots, SOA uses a distributed network architecture design approach that partitions service providers from service consumers using service discovery brokers to manage the process.

In the case of Google Earth, you, the service consumer (which is actually a software program running on your computer), specify the place on the planet you would like to see, and Google Earth's service discovery system locates available satellite images from US or international databases. Google Earth can either repackage the data for display and/or the satellite image service provider may provide its own display software for that purpose.

Figure 1. Traditional SOA model

Self-contained services communicate with each other when required; yet they do not depend on the state of other services, creating a loosely coupled architecture that is easily reconfigurable. The SOA approach is attractive for complex System of Systems (SoS) designs because of its flexibility and reusability, and its isolation of functionality from the details of implementation. The roles commonly described in SOA are service provider, service consumer, and service discovery broker. The service provider offers services, making them available by publishing service interfaces in a service registry. The service consumer uses service provider services based on published service interface rules. The service discovery broker component manages the registry for both providers and consumers.

In general, the elegance and appeal of SOA is multifaceted. For example, service consumers do not necessarily need to be specially reconfigured to take advantage of or even locate new services. Google Earth simply was suddenly available for millions of users without downloading or installing new software. Rapid SOA deployment provides strategic time-to-market and cost advantages for companies like Google as well as its customers.

Another potential advantage is that if properly configured, a service consumer can locate new or novel services simply by requesting the service provider to find them. Service providers can make themselves instantly known to all service consumers by publishing their new services to the service discovery broker, too. Conceptually, SOA-based systems provide flexible, reusable, cost-effective tools and services that benefit the consumers, providers, and discovery agents.

Naturally, these tools are browser based, allowing free data and service dissemination via the Internet using ubiquitous browser software like Internet Explorer, Firefox, Opera, or Safari. The dependence on the Internet is why SOA systems are also referred to as "net-centric." SOA's dependence on software and data provided by distant Web-based service providers is why they are called Web apps or Web services, too. In the case of Google Earth, these services are free, in exchange for giving Google's permission to display—and sell—context-sensitive advertising to users. Other SOA systems, such as online poker or investment software, may use direct-user fees as the business model to subsidize system development.

Companies like Microsoft have long expressed strong enthusiasm about SOA's ability to create new software as service (SaS) models to distribute productivity tools like word processing. They claim that SaS could ultimately spare everyone the cost and expense of buying and updating full office automation software, especially when most users barely do more than write an occasional memo or e-mail. In the SaS model, users could pay a small per-use fee for whatever functionality they need, and Microsoft would take care of guaranteeing that all updates, bugs, and new features are promptly and correctly installed. (By the way, some of you who had IT careers back in the 1970s may remember something like SaS and SOA by a different name: timesharing! The driving rationale today is different, but the economic models are quite similar.)

In the health care world, hospitals and manufacturers are exploring SOA strategies to integrate disparate departmental patient databases and systems, including admissions, cardiology, laboratory, and MRI that also may be distributed across multiple institutional partners' facilities. These early successful health care SOA research projects usually include the following basics:

1. Selecting a common SOA infrastructure from a provider such as BAE, IBM, Mercury, or Microsoft;
2. Writing or contracting an interface for each departmental system to and from the SOA platform; and
3. Implementing and managing the service discovery broker so that it matches service consumer (the physician's office, for example) requests to the correct service supplier—the hospital laboratory information system, for example—and ensures that the service consumer has the correct software specifications to allow displaying the data.

The Health Care Connection

Applying SOA to health care, however, places more burdens on SOA solutions than Google Earth does because of legal and life-safety implications. A few examples can help illustrate some of the challenges:

• In the traditional SOA model, the infrastructure, users, and services are generally static. For example, retail stores or manufacturing plants can usually provide robust network and server access within their entire facility. Similarly, a single-hospital SOA could use the hospital's admission, discharge, transfer system as its "patient registry service provider," allowing all departmental computer systems to query patient names, addresses, and other demographic and billing data. On the surface, the elegance of the SOA architecture could allow a new service consumer, like a hospital's new home care business, to plug into SOA immediately to help manage its home care activities. The home care employees would simply become new service consumers, and might only need to create a single interface from their laptop computers to the hospital's SOA system. Unfortunately, if many of their home care sites were beyond reliable regional Internet access, the visiting nurses could find their systems were frequently useless. SOA-based systems are inherently interdependent, and traditional SOA implementations assume constant and reliable access to all necessary components. A failure like this in health care is not simply inconvenient; it may prevent relaying life-critical lab results, drug allergies, or other information at the moment and place of care, placing the patient at risk.
• Even simple health care applications have to deal with Health Insurance Portability and Accountability Act of 1996 (HIPAA) privacy and confidentiality concerns. Mobile users—like the previously mentioned home care nurses—can cause unique challenges, especially if many different nurses, and student nurses, visit the homebound patient on differing days and schedules. For health care uses, the service discovery broker software may need very complex, custom-written security and authentication features to ensure that each request by a physician meets all relevant state and federal HIPAA restrictions, and that all violations are also properly reported and logged to an audit file.
• An SaS health care solution might, on the surface, look economically and operationally attractive. Health care institutions rapidly accumulate terabytes—and even petabytes—of archived digital data, however, and those files must often be retained in the same format in which they were created to prevent flaws or legal claims of tampering. While it may sound great to always have the latest video display software updates, a hospital must be able to ensure it will be able to display 5-, 10-, or even 20-year-old file formats reliably, even if the software company abandoned them long ago.

The examples above should be instructive, because they reveal the hidden management obligation that comes with all SOA projects, sometimes called SOA governance. In essence, most SOA users have to keep in mind that there is no free lunch. In exchange for the flexibility and advantages that SOA generally offers, each institution needs to provide strong, consistent, and competent leadership to ensure that all the pieces work together throughout their long life cycle of ownership. This stewardship is sometimes labeled an SOA governance center of excellence, and it describes a team of internal and outside professionals who keep a very close eye on all the contracts, technical standards, complex SoS verification and validation strategies, and the myriad of underlying interdependent services that a successful SOA system absolutely depends on.

Is there a service oriented architecture in your future? Probably. I hope this information helps you feel more comfortable, and more thoughtful, about the benefits and risks!

Elliot B. Sloane, PhD, Villanova University; cochair HIMSS/RSNA/ACC IHE Strategic Planning Committee; cochair ACCE/HIMSS IHE patient care device domain. For more information, contact .