Improving Performance of Healthcare Systems with Service Oriented Architecture

SOA in Healthcare

The rapid rise of technology and its adoption into the healthcare field has caused healthcare organizations to collect an accumulation of non-interoperable systems that not only need to work together within the organization, but are also accessed from outside. The burden of integration usually falls on the users of the system, who are forced often to access many different systems to complete one task. The use of a service oriented architecture (SOA), however, can improve the delivery of important information and make the sharing of data across a community of care practical in cost, security, and risk of deployment.

Healthcare organizations today are challenged to manage a growing portfolio of systems. The cost of acquiring, integrating, and maintaining these systems are rising, while the demands of system users are increasing. Organizations must address evolving clinical requirements as well as support revenue cycle and administration business functions. In addition, demands are increasing for interoperability with other organizations to regionally support care delivery. Service oriented architecture offers system design and management principles that support reuse and sharing of system resources across the healthcare organization. SOA does not require the re-engineering of existing systems. With SOA, existing processing can be combined with new capabilities to build a library of services that are used as a part of solutions. Using shared services that are aligned with business processes, SOA strengthens interoperability while reducing the need to synchronize data between isolated systems. Services may be made available, no matter their location, to create solutions that reach beyond the desktop, the department, and the healthcare organization.

Introduction to the Use of SOA in Health Information Technology

A healthcare organization that depends upon a single system across the entire enterprise to support various departmental and care delivery needs often already has a solution that shares and reuses system resources. More typical is an organization that depends upon one or more enterprise-wide systems, supports department-specific needs with additional systems, has facilities that use their own instances of systems, and interoperates using a complex network of data interfaces. The organization that has a large portfolio of systems will more readily see the benefits of SOA. An SOA environment enables system assets to be accessed across the organization, providing opportunities for sharing system capabilities that are currently isolated. For example, SOA can help meet unfulfilled processing requirements without purchasing additional systems and can provide opportunities to standardize processing and data management. This means existing system capabilities increase in value as they are packaged and shared as services. Figure 1 presents examples of healthcare system functions and related applications. Though this figure does not contain a complete list of functions or systems, it shows the redundancy of system functions in a typical healthcare environment.

Figure 1 - Healthcare Systems and Functions

SOA defines a service as an independent unit of work that is self contained and has well-defined, understood capabilities. A unit of work may be an entire process, a function supporting a process, or a step of a business process. With SOA, services directly support business processes as they are "discovered" and orchestrated as a system solution. The greatest opportunities for applying SOA to increase reuse and standardization are provided by those functions that are used across systems, departments, and organizations. If system functions are redundant across systems, then the corresponding business processes are likely related and may indicate the need for process sharing as services. In Figure 1, functions with substantial redundancy are:

• Register patient
• Admit, discharge, and transfer patient
• Document problem and diagnosis
• Capture and document charges
• Create clinical note

Each system function may be separated into tasks to further increase reuse opportunities for services. For example, the function "register patient" may be separated into the tasks "find and view patient record," "create and update patient record," "verify insurance eligibility," "document history" (new or update), and other business activities completed during the registration process. This granularity allows other services and applications to use parts of the "register patient" function. The task "find and view patient record" may be used by most of the organization, whereas the task "create and update patient record" may be used only by the admission and front desk staff. In some cases, the capabilities provided on another system may be superior to the capabilities currently being used in a process. For example, another system may use a "verify insurance eligibility" function that provides more capabilities than the corresponding item residing in the system on which the "register patient" function is processed. SOA provides an environment in which functions can be standardized and used across systems and processes.

Figure 2 presents a conceptual view of the "register patient" services function:

Figure 2 - "Register Patient" System Function

As SOA is further adopted by the healthcare industry, collections of services as well as specific services will be available for adoption and use by a healthcare organizations Service Procurement organizational function (as described in Chapter 2). Since the location of a system providing services is transparent, these acquired services may be hosted outside the organization. For example, a Diagnostic Related Group (DRG) or other similar controlled medical vocabulary coding services may be available for integration into an organization’s solution. The service may be located on an outside agency’s system and used by a variety of healthcare organizations. An additional advantage enabled by SOA is that a single DRG code set can be easily kept up-to-date for the entire organization as well as for all healthcare organizations using the service. Figure 3 illustrates an example of service taxonomy for healthcare.

Figure 3 - Example Service Taxonomy for Healthcare

Addressing Healthcare Data Integration with SOA

In most healthcare organizations, a nurse uses multiple systems and devices while providing patient care. The nurse may switch from a patient management application for checking demographics and admission information to one or more electronic medical record (EMR) applications for viewing clinical notes on prior and current problems, to a charge collection application for ensuring correct billing, and to multiple ancillary systems for requesting an order. If the nurse does not have access to a system that supports contacting a patient’s physician or reviewing another organization’s clinical records, the nurse may need to complete these functions by phone or fax. These systems and activities support functions required to complete the overall care delivery process. In this example, however, nurses-not the system-orchestrate the various systems to support their work. The nurse is providing the interoperability.

Traditionally, healthcare organizations have supported interoperability by synchronizing data between various systems-as many as a hundred or more in some organizations. Patient information is managed in almost all of these systems. System databases are synchronized using data interfaces and, for less critical systems, duplicate data entry. Initially, data interfaces between systems were point-to-point, with each system having its own message format. As the number of systems increased, standard interface formats, such as Health Level 7 (HL7), and central data interface engines have been adopted by larger healthcare organizations. In addition, Internet-based communication has allowed organizations to exchange data with external organizations, such as payers. Figure 4 presents a common healthcare data integration architecture. This environment includes various types of servers, older point-to-point interfaces, and many interfaces processed through a data interface engine.

Figure 4 - Common Legacy Healthcare Data Integration Architecture

Though data is synchronized between systems and system databases within and outside the organization, this data interface approach falls short of supporting data interoperability. Data processing and communication between processes involves multiple systems and redundant processing. To support the overall workflow, users must switch between several applications to complete a process. Systems must also be cleared of redundant data. With SOA, services are developed using existing system capabilities, as shown in Figure 5.

Figure 5 - SOA Integration Architecture for Healthcare

With SOA, system processing is organized and represented as a set of services. Each service is made available to the entire organization through a standard interface. All departments that maintain or access the same information use the same service, making any data and processing redundancies transparent to users. Applications supporting a specific workflow reference one or more services, and each service communicates with the systems to which it is related. Users no longer need to switch between systems to complete a workflow and data is naturally synchronized across processes and supporting systems. Orchestrated services aligned with user workflows enable true interoperability among the healthcare organization’s processes and people. To support compliance with the Health Insurance Portability and Accountability Act (HIPAA), organizations are increasing standard data communication with payers. In addition, integration with other healthcare organizations is frequently required to support clinical workflow and healthcare information network (HIN) participation. An organization may integrate external services into its SOA solution to provide complete process interoperability. For example, when a patient is registered within an organization, the service may use an external service provided by the HIN to register the patient for the entire community of care. Not only is the patient’s registration information synchronized, but this external communication is placed into the related workflow with little user impact, creating interoperability outside organization system boundaries.

SOA is the next step of system evolution. It builds upon previous architecture approaches while better addressing agility and effective reuse across and outside the organization. SOA provides true interoperability. Most healthcare organizations have a large portfolio of systems with redundant processing and data. SOA allows system capabilities to be selected and packaged as services that are better focused and available across the entire organization. Organizations can shift their efforts from maintaining a complex data interface strategy to creating service-oriented applications that support interoperability while more closely aligning with healthcare processes. Throughout the remainder of this chapter we explore these themes of how true healthcare data interoperability through SOA can yield an industry transformation in healthcare.

SOA for Health Information Networks (HINs)

Data integration and interoperability is a key requirement in healthcare. Medical errors that cost dollars and lives are most often the result from the lack of the right information being available in the right form at the point of care.

Worldwide, solving this problem is a key focus area for many governments and associated healthcare institutions. Healthcare information networks (HINs) are the means by which the data integration problems are being addressed. A HIN is a collaboration among the government, hospitals, specialty labs and pharmacies, as well as insurance agencies (payers) to provide a network of data exchange that builds a shared information pathway, data repositories, and application interfaces to rapidly and accurately exchange key health information across a system of healthcare.

HINs are put in place to support the following main usage models:

• Exchange of patients’ electronic medical record between one care provider and another in order to get key information like the patients’ medical history, allergies, persistent medical problems, and current medications and active treatments
• Exchange of referrals between primary and secondary care providers or labs as well as the medical results of those referral visits
• Electronic pre-authorization of treatment so that it is known quickly whether a treatment or drug is supported by the patient’s insurance plan
• Electronic claims filing and payment to increase the accuracy and speed the cash flow cycle of medical care
• A means to electronically order and monitor consumption of prescriptions
• A consolidated data repository of key healthcare information for legally mandated bio-surveillance activities (such as influenza or other disease outbreak)
• A portal for the patient and healthcare stakeholders means for accessing appropriate data

Figure 6 gives a graphical depiction of the architecture of an SOA-based HIN.

Figure 6 - HIN Actors

Creating a Sustainable HIN

The key challenge to implementing a HIN is creating a sustainable financial model where the costs and risk to bring up the network are tolerable by the community of care and that there is a recurring source of value to justify ongoing operational costs of maintaining the network. Even in communities where the government (local, regional, or national) is providing the funding for the greater good of the community, these issues of cost, value, and sustainability are still material considerations.

Using legacy mechanisms of healthcare data integration are simply not financially feasible to implement and sustain a HIN over the long term. If every time a new hospital, pharmacy, or government agency was brought on to the HIN a new point-to-point/broker interface is developed the following architectural and cost problem is created, which is depicted in Figure 7.

Figure 7 - Diagram of the Point-to-Point/Broker Integration Architecture

What happens in the point-to-point/broker-based method of integration is that the number of systems interfaces grows exponentially relative to the number of participants in the HIN. A study done by Canada’s Health Infoways1 clearly shows how futile this legacy approach to integration is from a cost and sustainability perspective:

• Cost of one integration: Simple = 32,000 Canadian dollars (CAD); Medium = CAD 95,000; Complex = CAD 190,000
• 38,783 systems in Canada
• Number of types of integrations: Simple = 4,527; Medium = 20,081; Complex = 14,175
• This yields 1.5 billion system interface points
• Estimated cost is approximately CAD184 billion

This Canadian example clearly shows that establishing a HIN of scale using point-to-point integration architectures is not viable from a cost standpoint. At the time of this writing, 234 regional HINs are being put up in the USA by various state and local governments who each are spending approximately USD 2-5 million per HIN. More than 70 percent of the initial startup costs for these HINs are on the systems integration to bring the first hospitals and insurance companies on the information network. For HINs to sustain their costs over the long term, these economics must change.

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 8 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 8 - 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 9 describes this architecture and some example shared services.

Figure 9 - 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 10 is a diagram of the service bus architecture.

Figure 10 - 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 worldwide 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 11 summarizes the reasons for this low adoption rate and shows how SOA can help increase EMR adoption.

Figure 11 - Barriers to Electronic Medical Record (EMR) system adoption

Using SOA techniques can address many of the issues described in Figure 11 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 7.12 describes this architecture.

Figure 12 Architecture for Integrating Hosted and Outsource Applications

For more information about improving the performance of healthcare systems with SOA, please refer to the book Service Oriented Architecture Demystified by Girish Juneja, Blake Dournaee, Joe Natoli, and Steve Birkel, published by Intel Press.

About the Authors

Girish Juneja is the director of SOA products at Intel, with more than 15 years of experience in the technology industry in engineering and technology strategy.

Blake Dournaee is currently the product manager responsible for Intel SOA products. Blake is an established author who wrote the first book on XML Security.

Joe Natoli is a platform architect in the Digital Health Group at Intel. Joe was a founding member and architect of the SOA strategy and planning program for Intel IT.

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

Copyright © 2008 Intel Corporation. All rights reserved. This article is based on material found in book Service Oriented Architecture Demystified by Girish Juneja, Blake Dournaee, Joe Natoli, and Steve Birkel. Visit the Intel Press web site to learn more about this book: http://www.intel.com/intelpress/sum_soa.htm.