Service Oriented Architecture (SOA) Implications for Large Scale ...

Proceedings of the 1st Distributed Diagnosis and Home Healthcare (D2H2) Conference Arlington, Virginia, USA, April 2-4, 2006

Service Oriented Architecture (SOA) Implications for Large Scale Distributed Health Care Enterprises Eugen Vasilescu, Member, IEEE, Seong K. Mun, Member, IEEE 

three levels of increasing abstractions, at the bottom level: individual standard based transactions are defined at the level of messaging structure(HL7, DICOM); at the middle level: transactions performed by a logically functional capability are aggregated as “Actors”; at the top level: Integration Profile: collection of Actors and transactions logically induced by a specific clinical integration need. Through these profiles domain specific interactions (such as those among Hospital Information Systems, , Radiology Information Systems, Picture Archiving and Communication Systems) are seen as an assembly of Actors fulfilling specific functional needs. Additionally, the IHE IT Infrastructure Technical Framework (ITI TF) [2], [3], defines specific implementations to achieve integration goals promoting interoperability of health care information. These profiles, such as Retrieve Information for Display (RID), Patient Identifier Cross-referencing (PIX) have applicability irrespective of clinical domain. IHE profiles go to an “integration level of detail” that prove specific enough for achieving integration among disparate vendors in just a few weeks during regular connect-a-thons. These profiles are on purpose silent on particular implementation choices and do not focus on key characteristics (such as scalability, availability, flexibility, extensibility) which are paramount for large scale distributed health enterprises. These characteristics can be promoted though by specific (and to a significant part complementary) architectural approaches such as “Service Oriented Architecture” (SOA) [4]. Thus the transitioning to SOA by large scale distributed health enterprises has a high potential payoff. This paper discusses the main characteristics of SOA and its implications for large scale distributed health enterprises in terms of achieving accepted SOA characteristics and their relationship to IHE. It also highlights the main challenges in transitioning to SOA encountered by large scale health enterprises from the viewpoint of benefits and cost/risk factors. Thus this paper is directly relevant to critical aspects of Electronic Health Records standardization, policies, strategies, integration and interoperability in large scale distributed environments.

Abstract—Large scale distributed health care enterprises need to focus on characteristics such scalability and availability enhancing the integration and interoperability elements provided by the IHE profiles. These characteristics are promoted by architectural approaches like SOA. The paper details main characteristics of SOA-based components and services and their (complementary) relationship to IHE. It also highlights expected challenges in transitioning to SOA encountered by large scale distributed health enterprises from the viewpoint of benefits and cost/risk factors.

I. INTRODUCTION Large scale distributed health enterprises as currently deployed by Department of Defense (DoD) , Department of Veterans Affairs, large HMOs and others have operations covering large geographical areas and millions of patients supported in dozens of locations by different platforms and vendor’s products. Their integration and interoperability needs go significantly beyond the type of challenges faced by (relative) smaller providers. The healthcare community integration and interoperability efforts are centered on the Integrating the Healthcare Enterprise (IHE) initiative and for obvious market reasons has as primary focus the latter category. IHE is a bottom-up effort started by the health care community including industry, users, academia, because of the perception that there is a gap between standards that make interoperability possible (such as HL7, DICOM and others) and actual implementation of interoperable systems. Industry realized that one can have very expensive site specific interfaces among standard compliant systems. To help solving this problem, the healthcare community started IHE as a gap bridging effort based on achieving a consensus (reference) framework implementation of most common capabilities. These framework implementations of common capabilities are documented in the IHE Technical Framework via Integration Profiles [1] characterized by Manuscript received December 15, 2005. This work was partially supported by contract N01-LM-3-3506 from the National Library of Medicine and DoD HA contract W74V8H-04-P-0084 E. Vasilescu, Seong K. Mun are with the Imaging Science and Information Systems (ISIS) Center, Department of Radiology, Georgetown University, Washington DC, USA (phone: 202-687-1587; fax: 202-784-3479; e-mail: [email protected]; [email protected]).

1-4244-0059-7/06/$20.00 ©2006 IEEE.

91

II. SOA BACKGROUND AND LARGE SCALE DISTRIBUTED HEALTH CARE ENTERPRISE CONSIDERATIONS

and domain model iterations, while the Description orientation might be achieved through a relatively speedy introduction of interface languages or descriptions. In fact deciding when a particular SOA-based service or component can be transitioned into production is a complex undertaking. This is particularly true of specific clinical services and components. As an example a Person Identity (PIDS) Service [6] has a fairly established logical view and the granularity is well researched because of traditional expertise applicable to various clinical domains is captured in the available standard. For instance, the standard established a consensus approach on handling the core requirements: Support the assignment and correlation of identifiers, support searching and matching of people based on attributes, support federation of PIDS services, and allow for PIDS implementations to protect person confidentiality. Unlike PIDS, an Order Entry service may take several design iterations before arriving at an acceptable logical view even though there is a body of HL7 messages supporting most of the functionality. For instance in [1] Actors such as Order Filler or Order Placer of the Scheduled Workflow profile may need extensive revisions to generalize their functionality to cover besides Radiology, other clinical (and non-clinical) domains. Enterprise order entry systems routinely include coded procedure information from each of the major ancillary systems, e.g. pharmacopoeia, radiology procedure codes, lab procedure codes, etc. Ordering may be generalized to handle administrative and logistical functions as well (e.g. purchase orders, admission and discharge, nursing, and others.) A minimal set of attributes are common regardless of order types: priority, comments/notes, frequency (time), and order distribution, however the operational requirements are quite complex and difficult to standardize. There are, depending on particular clinical domain a variety of order kinds: Simple order, Compound Order, Complex Order, Conditional Order, Linked Order, Sliding Scale Order, Tapering Dose Order. Thus it is not unusual for an end-user of a large scale distributed order entry system to require handling of data elements in excess of the ones explicitly supported by the desired IHE profile, and new messages may need to be supported, sequenced or aggregated in unpredictable ways to achieve the desired logical view or granularity. These considerations highlight the fact that pronouncing a service or component “SOA mature and ready” is part art and part science. They also point to the need for a high level classification of SOA-based components and services based on the five SOA characteristics above and an associated process for deciding and achieving, based on the chosen high-level classification, of the desired SOA characteristics for large scale health enterprise components and services. The most common implementations of SOA rely on the use of Web Services [7] with components invoked via SOAP [8] messages. Interfaces are described using WSDL [9], and discovery is achieved via UDDI [10]. Web Services are currently evolving and a large number of new standards and capabilities are being added. There are several dozen

SOA is traditionally defined as a set of components that can be invoked, and whose interface descriptions can be published and discovered. By (system) Component one understands that a unit of software encapsulates a certain functionality or service. It has a clearly-defined interface and conforms to a prescribed behavior common to all components within an architecture. A service is a capability offering a coherent functionality from the point of view of provider’s entities and requesters entities. A service may be implemented by one or more components. The Web Services Architecture [4] defines SOA as a form of distributed systems architecture characterized by: [1]

Logical View: The service is defined in terms of what it does—normally a business-level operation.

[2]

Message Orientation: An exchange between provider and requestor programs done exclusively via messages.

[3]

Description Orientation: The service is described in machineprocessable metadata.

[4]

Granularity: Involves relatively few operations with relative large messages.

[5]

Platform Neutral: Messages sent in a neutral way and obey welldefined interfaces.

While IHE is not an architecture, there are similarities in emphasis between SOA and IHE: both rely on functional descriptions – Logical Views for SOA and Actors for IHE, and on Messages – Message Orientation for SOA and detailed interactions mostly expressed via HL7 messages for IHE. Unlike IHE, for SOA is important that service metadata description have as much semantic content as possible, and the granularity of messages should be designed in a relative coarse manner (consistent with say the “façade” design pattern of [5]) and thus more scalable (chatty interactions do not scale well on the internet). Finally the Platform Neutral characterization of SOA means in practice an XML bias for expressing message content, while IHE due to its legacy support requirements uses a HL7 version predating the XML-based v3. The five required characterizations defining SOA are likely to be, in any particular instance, in an uneven state of maturity, and each characteristic may evolve at a different speed rate. For instance, the Logical view and the Granularity characteristics are likely to evolve through several business 92

Web Services in various stages of maturity and adoption dealing with state, security, messaging, etc. Web Services are not always the best choice for SOA implementations. In fact, one can successfully practice SOA within mainstream distributed environments such as J2EE or .NET. However, SOA implementation via Web Services may be considered when applications must operate over the Internet where reliability and bandwidth cannot be guaranteed, when personnel resources for remote deployment and management are scarce, when there is a mix of platforms and vendor products. These constraints are usually present in large scale distributed health care enterprises.

satisfying any of the SOA characteristics) that may however have the advantage of a fairly complete functionality and potential for modularity/partitioning and migration to J2EE or .NET environments. A mature target SOA-based service or component would depend on satisfying reasonably complete SOA characteristics in Web Services environments, or in one of the mainstream distributed environments (J2EE, .NET). Intermediate classification rankings would be required as meaningful evolutionary steps and they need to track significant evolutions of Logical View and Granularity SOA characteristics. There is general agreement that transitioning to SOA is unavoidable. This is recognized by users of large scale scale heterogenous distributed systems, including DoD [11]. There is however a temptation to expose legacy systems as Web Services, through either automatic code generation tools or through well established methodologies, and state that a SOA transition was achieved. This way one can wrap legacy client/server systems with limited scalability and bring them into Web Services environments without any refactoring or redesigning and little regard for achieving SOA characteristics. It is through mature services and components that large enterprises achieve SOA-based architecture benefits. The benefits accrue from improved layering and flexibility as characteristics such as Message orientation, Description orientation, Platform neutrality enable loose coupling of components across heterogeneous platforms, ease of maintenance and integration, easier discovery, use and aggregation of services and components, The IHE rough division of its Profiles in technical infrastructure profiles (such as PIX, RID) and technical (domain specific) profiles (such Scheduled Workflow for Radiology domain) is of special significance within the SOA context. It points to the need in large distributed health care enterprises to take into account two categories of services and components: foundational (such as messaging, identity, security) and application specific ones (order entry, results retrieval, image archiving). The foundational services components will normally participate as building blocks in application specific ones. It is usually desirable to place foundational services on the critical path for early adoption/incorporation by the application specific services. This division into foundational and application specific services is already recognized as applicable and useful within large distributed health care providers like DoD Health Affairs (HA) [12]. Transition to SOA requires as well the management of significant administrative/organizational risk. Transitioning to SOA may create unusual organizational strains because most health care entities are not equipped to account for shared services which may vary rapidly in content, complexity and use across the organization. There are traditional divisions and barriers between some departments and ancillary services and, at higher levels among hospitals and administrative entities. These divisions

III. TRANSITIONING TO SOA IN LARGE DISTRIBUTED HEALTH CARE ORGANIZATIONS Technology transition is mainly controlled by the interaction of four factors: one is the cost/risk factor which normally decreases in time; the other is the benefit factor. When the technology benefit outweighs the cost/risk factor it signals that the adoption of the technology may be desirable for the enterprise. These two factors apply equally to commercial environments and Government and are the focus of our technology transition considerations. The other two factors are competitive pressure and regulatory compliance. Competitive pressure is primarily a commercial environmental issue. However, regulatory compliance affects both commercial and Government in a similar manner. For example, HIPAA caused a technological transition for all healthcare organizations. The introduction and adoption of the technology is nearly optimal when it is timed approximately near the point when the benefits outweigh the cost/risk factor. While the technology transition processes have general purpose drivers, there are specific considerations when SOA components/services are assessed. From a business process and strategy perspective SOA benefits accrue when both key projects and the enterprise as a whole incorporate via SOA components and services vital information needs. Proven benefits can be obtained when quantitative measuring criteria are in place and accepted by all concerned decision makers. The use of shared services for reducing costs needs to be monitored for a correct SOA impact assessment, which depends heavily on careful mapping and alignment of business processes on underlying SOA services with the matching logical view characteristics. The use of IHE profiles and its actors may provide a guide and first approximation in this mapping process. The main technical risk factors are tied to correct assessment of SOA components and services maturity. Managing technical risk factors may be facilitated by a classification of services and components based on the five SOA characteristics listed above: an initial (low) starting point may be a pre-SOA component (not necessarily 93

[7]

World Wide Web Consortium. Web Services Activity. [Online]. Available: http://www.w3.org/2002/ws [8] World Wide Web Consortium. SOAP. [Online]. Available: http://www.w3.org/TR/soap [9] World Wide Web Consortium. (2001, Mar) Web Services Description Language (WSDL) 1.1. [Online]. Available: http://www.w3.org/TR/wsdl [10] Organization for the Advancement of Structured Information Standards (OASIS). Universal Description, Discovery, and Integration (UDDI). [Online]. Available: http://www.uddi.org [11] Net-Centric Checklist, Version 2.1.3, Office of the Assistant Secretary of Defense for Networks and Information Integration/Department of Defense Chief Information Officer (12May2004) [12] Georgetown University, “Transitioning to MHS Specific Service Oriented Architecture” (SOA) Components and Services”, draft version report to DoD HA, 0.95 - July 28, 2005

and barriers are not easily bridged, especially in an environment that values specialization. The acquisition/development processes of new IT systems are normally project oriented and so are the software development methodologies, supporting tools, and ongoing operational processes and practices. This increases the chance of local optimization of projects to the detriment of global enterprise optimization. The creation of new organizational framework based on an “Enterprise of Services” approach may be necessary to support SOA shared services methodologies. IV. CONCLUSION The IHE efforts to improve the integration and interoperability of large scale healthcare enterprises need to be complemented by the use of SOA-based components and services. Large scale distributed healthcare enterprises require architectures that offer more than enhanced interoperability and integration potential at local level. It is through SOAbased component and services that integration and interoperability can be scaled up and bridge clinical and related administrative entities with improved flexibility regardless of platform and physical location, While transitioning to SOA-based components and services promises high payoffs, they are conditioned on a number of factors including: - Monitored alignment of business processes with underlying SOA services consistent with IHE profiles. - Adequate technical risk management focused on SOA component and services classifications and controlled maturing processes - Organizational/Administrative risk management driven by the unimpeded creation of an “Enterprise of Services”.

REFERENCES

[1] [2] [3] [4] [5] [6]

ACC, HIMSS and RSNA: IHE Technical Framework, vol.1, Integration Profiles, Revision 6.0 – Final Text, May 20, 2005, http://www.ihe.net/Technical_Framework ACC, HIMSS and RSNA: IHE IT Infrastructure Technical Framework, vol. 1 (ITI TF-1): Integration Profiles, Rev 2.0 August 15, 2005, http://www.ihe.net/Technical_Framework/index.cfm ACC, HIMSS and RSNA: IHE IT Infrastructure Technical Framework, vol. 2 (ITI TF-1): Transactions, Rev 2.0 August 15, 2005, http://www.ihe.net/Technical_Framework/index.cfm Web Services Architecture [http://www.w3.org/TR/ws-arch/ E. Gamma, R. Helm, R. Johnson, and J. Vlissides, “Design Patterns: Elements of Reusable Object-Oriented Software”, Addison Wesley, 1994. Object Management Group. (2001, April) Person Identification Service. [Online]. Available: http://www.omg.org/technology/documents/formal/person_identificati on_service.htm

94