ServiceTechMag.com > Archive > Issue XVII: April 2008 > SOA in Healthcare - Part I
Girish Juneja

Girish Juneja

Biography

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.

Contributions

rss  subscribe to this author

Blake Dournaee

Blake Dournaee

Biography

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.

Contributions

rss  subscribe to this author

Joe Natoli

Joe Natoli

Biography

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.

Contributions

rss  subscribe to this author

Steve Birkel

Steve Birkel

Biography

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.

Contributions

rss  subscribe to this author

Bookmarks



SOA in Healthcare (Part I)

Published: April 15, 2008 • SOA Magazine Issue XVII
 

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, especially considering that SOA often does not require the reengineering of existing systems. For example, the application of service-orientation allows existing processing logic to be combined with new capabilities in order to build a library of services that can then be used as the basis for many different solutions.

This two part article based on excerpts from the book "SOA Demystified" 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. Services may be made available, no matter their location, to create solutions that reach beyond the desktop, the department, and the healthcare organization as a whole.


Introduction: SOA and 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.

Here are some typical characteristics of such an organization:

  • it depends upon one or more enterprise-wide systems
  • it supports department-specific needs with additional systems
  • it has facilities that use their own instances of systems
  • it interoperates using a complex network of data interfaces

When type of an environment has a larger portfolio of systems, the benefits of SOA will more readily come to light. A service-oriented technology architecture 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 further 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 some examples of healthcare system functions and related applications, and reveals the potential redundancy of system functions that can exist in a typical healthcare environment.



Figure 1: Common 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:

  • 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 (Figure 2). SOA provides an environment in which functions can be standardized and used across systems and processes.



Figure 2: A sample "Register Patient" system function.

As SOA is further adopted by the healthcare industry, collections of services will become available for adoption and use by healthcare organizations.

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) service may be available for integration into various different solutions. This type of 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: An example service taxonomy for healthcare.

Figure 3 illustrates an example of service taxonomy for healthcare and here are some related examples of core healthcare business services:

  • Medical Service Provider (organization and affiliation relationships, plus roles and groups)
  • Patient (including MPI)
  • Scheduling and Appointments
  • Service Provider Order (labs, treatment, pharmaceuticals)
  • Encounter (including clinical results and recommendations)
  • Health Record (summary or full history)
  • Insurance (claims and referrals)
  • Accounting (hospital GL)
  • Document (scanned paper or DICOM image)

Addressing Healthcare Data Integration with SOA

In most healthcare environments, 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 finally 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 institutions. In addition, Internet-based communication has allowed organizations to exchange data with external partners, 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: A 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: A service-oriented integration architecture for a healthcare enterprise.

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 partners is frequently required to support clinical workflow and healthcare information network (HIN) participation. An organization may integrate external services into its service-oriented 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.

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 then shift their efforts from maintaining a complex data interface strategy to creating service-oriented solutions that support interoperability while more closely aligning with healthcare processes.

Throughout the remainder of Part 1 and 2 of this article series 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 are key requirements 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 most commonly being addressed. A HIN is a collaboration among government agencies, 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 for accessing appropriate data.

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



Figure 6: An overview of 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 was developed and the architectural and cost problems depicted in Figure 7 are the common result.



Figure 7: A common 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 Infoways [REF-1] clearly shows how futile this legacy approach to integration is from a cost and sustainability perspective:

  • Cost of one integration: Simple = $32,000 CAD; Medium = CAD $95,000; Complex = $190,000 CAD
  • 38,783 systems in Canada
  • Number of types of integrations: Simple = 4,527; Medium = 20,081; Complex = 14,175
  • Yield: 1.5 billion system interface points
  • Estimated cost: approximately $184 billion CAD

This 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 $2-5 million USD per HIN. More than 70 percent of the initial startup costs for these HINs are directly related to the systems integration required 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. In Part 2 of this article series, we will provide guidance as to how this required change can be attained with SOA.


References

[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: intelpress@intel.com. Intel is a registered trademark of Intel Corporation. Other names and brands may be claimed as the property of others.