• JUNE 2007 FEATURE ARTICLES •
Network Management
SOA in Healthcare
Sharing system resources while enhancing interoperability within and
between healthcare organizations with service-oriented architecture.
By Michael W. Bridges
Today’s healthcare IT organizations are challenged
to manage a growing portfolio of system
solutions. The cost of acquiring, integrating and
maintaining these systems is rising, while the
demands of system users are increasing. Organizations must
address evolving clinical requirements as well as continue
to support revenue cycle and administration business
functions. 
In addition to internal data integration needs,
demands are increasing for interoperability with other
organizations to regionally support care delivery.
Service-oriented architecture (SOA) offers system design
and management principles that support re-use 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, or to compose, 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.
Systems Reused and Shared as Services
A healthcare organization that depends upon
a single system across the entire enterprise to
support 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 enterprisewide
systems, supports department-specific needs with
additional systems, has locations that use their
own instances of systems, and interoperates using
a complex network of data interfaces.
An organization that has a large portfolio of
systems will more readily see the benefits of a
SOA. The use of SOA supports the enablement of
system assets with access across the organization,
providing opportunities for sharing system capabilities
that are currently isolated. With sharing,
current unfulfilled processing requirements may
be met without purchasing additional systems, and opportunities may become available for standardizing
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 table does not
contain a complete list of functions or systems, it shows
the redundancy of system functions in a typical healthcare
environment.
SOA defines a service as an independent unit of work
that is self-contained and has well defined and 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 re-use 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 most 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; and, Create
clinical note.
Each system function may be separated
into tasks to further increase re-use opportunities
for services. For example, the function “register patient”
may be separated into the functions “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
function “find and view patient record” may be used by
most of the organization, whereas, the function “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 function
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” set of services.
As SOA is further adopted by the healthcare industry,
collections of services as well as specific services
will be available for purchase or by subscription. Since
the location of system providing services is transparent,
it is even possible that services may be hosted
outside of the organization. For example, a Diagnostic
Related Group coding service may be available for
integration into an organization’s solution. The service
may be located at an outside agency, supporting use
by a variety of healthcare organizations. With SOA, it
is possible to have single instances of healthcare code sets, referenced using services, which
are always up-to-date for the entire
organization’s solutions.
True Interoperability
In most healthcare organizations,
a nurse uses multiple systems and
devices while providing patient care.
She may switch between a patient
management application to check
demographics and admission information,
one or more electronic medical
record applications to view clinical
notes on prior and current problems,
a charge collection application to
ensure correct billing, and multiple
ancillary systems to request an order.
If she does not have access to
a system that supports contacting a
patient’s physician or reviewing another
organization’s clinical records,
she may need to complete these functions by phone
or fax.
These systems and activities support activities required
to complete the overall care delivery process. In this example,
however, the nurse—not the system—orchestrates
the various systems to support her work. The nurse is
providing the interoperability.
Until now, healthcare organizations have supported
interoperability by synchronizing data between various
systems. Patient information is managed in most every
healthcare system, which can number above 100 in some
organizations. These system databases are kept 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 3 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.
As data is synchronized between systems
and system databases within and outside
the organization, this data interface approach
falls short of supporting true 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 also often must
be revisited to manually fine-tune data that is redundant
between systems.
With SOA, services are developed using existing system
capabilities, as shown in Figure 4. Redundant processing
is organized and represented as a single service or 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, organizations are increasing
standard data communication with payers. In addition, integration with other healthcare organizations is frequently
required to support clinical workflow and Regional Healthcare
Information Organization (RHIO) 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 RHIO, to register the patient for the entire region. Not
only is the patient’s registration information synchronized,
this external communication is placed into the related
workflow with little user impact, creating interoperability
outside organization system boundaries.
Conclusion
SOA is the next step of system evolution. It builds
upon previous architecture approaches while not requiring
complete re-engineering. SOA better addresses agility and
effective re-use across and outside the organization, while
providing true interoperability.
Most healthcare organizations have a large portfolio of
systems with much 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.
Michael W. Bridges
Sr. healthcare
enterprise architect with Intel Corporation.
Contact him at michael.w.bridges@intel.com.
