SOA in Healthcare (Part II)
SOA in Healthcare (Part II)
Join the DZone community and get the full member experience.Join For Free
SnapLogic is the leading self-service enterprise-grade integration platform. Download the 2018 GartnerMagic Quadrant for Enterprise iPaaS or play around on the platform, risk free, for 30 days.
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. This two part article 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. This two part article explores how healthcare organizations can leverage shared services...
This article authored by Girish Juneja, Blake Dournaee, Joe Natoli and Steve Birkel and published at SOA Magazine on March 2009.
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 1 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 1: 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 2 describes this architecture and some example shared services.
|Figure 2: 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 3 is a diagram of the service bus architecture.
|Figure 3: 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 world-wide 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 4 summarizes the reasons for this low adoption rate and shows how SOA can help increase EMR adoption.
|Figure 4: Barriers to Electronic Medical Record (EMR) system adoption|
Using SOA techniques can address many of the issues described in Figure 4 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 5 describes this architecture.
|Figure 5: Architecture for Integrating Hosted and Outsource Applications|
Implementing an SOA technology platform and associated organizational infrastructure is not something that can be done in a single event. In healthcare, this is especially true as very few organizations have the budget or can take on the operational disruption associated with tearing out and replacing key business systems in any form of wholesale fashion.
Therefore, major administrative, EMR, and ancillary healthcare systems should first be "fronted" with service interfaces that manage highly shared data and nearly universal redundant processing. In healthcare, that involves data regarding patients, providers, orders, and controlled medical vocabulary. Key highly shared functions include things such as a Master-Person Index (establishing a common record identifier across systems for patients and medical personnel), medical vocabulary translation, and verification of patient eligibility for services via their payer policy.
The key for a healthcare organization is to focus on getting a baseline service infrastructure in place that eliminates redundant entry, storage and transformation of their highly shared data across business processes, and those highly shared functions within the organization first and then look to extend their reach into the community of care through Health Information Networks. This is because most healthcare organizations have a complex application landscape internally and when connecting to a HIN will need to address the architecture, technology, and business implications of providing a standardized representation of their organization's data in order to feed it to and receive it from the HIN. Also, when it comes to evaluating where to start with SOA, it is important to focus on departments and business processes where the ratio of risk, cost, and benefit are most favorable. Often the areas of the healthcare business that will derive the most benefit from SOA architecture are those that also derive the most benefit from having quality, reliable and integrated data at the point of care such as emergency, critical care, and surgical departments and their associated patient care business processes.
Given this, the following are key tasks and milestones to pursue as part of a SOA maturity model in healthcare:
|•||Early Learning - Pilot the technology and organization shifts to SOA in one department on a targeted set of highly shared data and functions (such as patients, orders, and medical vocabulary in the admissions and order processes in the ER department).|
|•||Re-engineering - Extend the technology and organization investments to span departments on the highly shared data and functions as articulated above. Focus efforts on getting to organization-wide standards on this highly shared data and processing. Begin planning for HIN integration.|
|•||Integration - Implement HIN integration into core systems and departments as the roadmap evolves extended service integration into ancillary and administrative systems.|
|•||Maturity - A healthcare organization reaches a state of maturity when the SOA technology and organizational infrastructure permeates all major business processes, systems, and departments and supports the organizations HIN initiatives. This includes clinical and administrative systems.|
As with any SOA adoption program it is critical to start in a focused, targeted area of the business and build a "snowball effect" of results both in technology and business benefit.
Key Industry Challenges for SOA and Tactics to Address those Challenges
In the healthcare industry IT budgets are far smaller than in other industries such as manufacturing or financial services. It is very common to find budgets in the range of 1.5¡V2 percent of revenues, which is a third to a fifth of the IT budget in other industries. This extremely tight budget situation is further compounded by the fact that these dollars not only compete with things such as personnel, service offerings and facility costs, but also other significant technology assets; namely medical devices (like MRIs, infusion pumps, and so on).
This creates a "chicken-and-the-egg" dynamic for creating an SOA adoption roadmap in healthcare. Achieving the over 40-percent sustaining system and integration cost benefits that SOA offers is sorely needed when budgets are this tight, but at the same time how do enough precious dollars get freed up to sufficiently kick-start the Early Learning and Integration phases of the SOA roadmap?
Another key challenge in healthcare is the state of technology of many healthcare IT vendors. It is quite common for EMR, integration broker, and ancillary system technology vendors to still have products in "green-screen," mainframe, and minicomputer monolithic software technology stacks. Only a small set innovators have invested to bring their software architectures and technology stacks up to the n-tier, web-based technology stacks, but at the time of this writing they remain the suppliers with the minority market share and revenue.
The key tactic to address these issues is timing and finding the right project insertion point for your organization. Intercepting the deployment of a new EMR, department ancillary system, or HIN integration project are the hot new work for many organizations and offer enormous business benefit to be implemented using SOA techniques. Through Intel's interaction with many government and private healthcare organizations as well as the ISV community world-wide we anticipate the overall market to be entering the Early Learning phase of SOA in 2007 and progressing to Maturity post-2010 lagging other industries by 3+ years, which is a pace relative to all other forms of technology adoption in this industry segment.
|•||The application of SOA in healthcare can substantially reduce the complexity and redundant system processing of clinical information. It can also help to simplify and reduce the cost of participation in community of care health information networks (HINs), and can improve the cost and usability (and therefore reduce the deployment risk, leading to increased adoption) of electronic medical records.|
|•||SOA can provide a relatively inexpensive way to develop geographically independent and fault tolerant infrastructure, which is more easily upgraded than tightly bound system integrations. Availability can be increased through service redundancy.|
|•||Proofs of Concept (POCs) can be done with relatively light resource investment, yet can provide a power tool to enlist the support of technologists and executive management.|
|•||Due to the tight budgets in healthcare information technology, finding the right insertion project will be critical. A new SOA can build upon the momentum associated with a new EMR implementation, HIN project or organizational merger/acquisition--leveraging these inflection points can provide substantial advantage in SOA deployment.|
|•||As with any SOA adoption program it is important to start small and build on top of incremental success. In healthcare, that means focusing on the most critical business processes where highly shared data is required and in those processes where the timeliness and accuracy are most critical. This can translate to early SOA focus on patient, provider, order, and controlled medical vocabulary data in critical care settings such as ER, ICU, and surgical.|
[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: firstname.lastname@example.org. Intel is a registered trademark of Intel Corporation. Other names and brands may be claimed as the property of others.
This article was originally published in The SOA Magazine (www.soamag.com), a publication officially associated with "The Prentice Hall Service-Oriented Computing Series from Thomas Erl" (www.soabooks.com). Copyright ©SOA Systems Inc. (www.soasystems.com)
Published at DZone with permission of Masoud Kalali . See the original article here.
Opinions expressed by DZone contributors are their own.