October 24, 2011

A Service-Oriented Approach
By Selena Chavis
For The Record
Vol. 23 No. 19 P. 10

Can SOA help healthcare meet the challenges of data sharing and interoperability?

When it comes to data sharing, the needs of healthcare giants such as the Mayo Clinic, the U.S. Department of Defense (DoD), and the VA are mammoth, to say the least. Take that to the next level of health information exchange (HIE), and developing infrastructures that would successfully deliver needed patient information inside and outside these complicated systems could equate to a costly, inefficient mess.

It’s been the frustration of the healthcare industry for years—the inability to access patient data in multiple systems across separate organizations to achieve a patient-centric view that will take quality of care to the next level. While not the primary goal of stage 1 meaningful use (MU) criteria, the expectation going forward with stages 2 and 3 will be the ability to share data in a way that elevates patient care and quality metrics.

The question becomes how to develop technological infrastructures that will efficiently and effectively meet the end goal for the long term. And while experts agree it’s not the “end-all” answer, many large healthcare systems—including the Mayo Clinic, the DoD, and the VA—are finding that service-oriented architecture (SOA) is a move in the right direction.

SOA is a technological infrastructure that enables conversations to occur between numerous IT environments and program functionality to be reused across networks. Many industry professionals believe the technology holds significant promise in helping meet the data-exchange challenge.

“To make this really work at a national level, getting everyone on the same page for exchange … that’s critical stuff that needs to be addressed,” says Rick Geimer, chief technology officer (CTO) with Lantana Consulting Group. “When a patient’s entire longitudinal record can be accessed, it has the potential to revolutionize treatment.”

According to Kenneth Bobis, PhD, CTO and director at the Mayo Clinic, the organization operates three primary administrative sites: one (the largest) in Rochester, Minn., as well as satellite offices in Jacksonville, Fla., and Phoenix. After interviewing 30 developers within these operational centers, he determined that the ability to share components already written within the system would be a positive step toward creating efficiencies with development and improving data sharing.

The Mayo Clinic has close to 2,000 clinical applications within its two EMRs, and building an integrated platform for data sharing among these applications was daunting at best. Leveraging the promise of SOA, Bobis and his team moved forward with creating an environment where data would be reusable and no separate interfaces would be needed between the applications.

“Now they provide Web services to any application that wants that data,” he explains, noting that the term “Web services” essentially refers to an SOA infrastructure. “We’re using SOA for interoperability.”

Following many attempts to successfully bring their clinical databases together, the DoD and the VA also made the decision to operate their EMRs over an SOA in 2008. The new infrastructure is helping the two entities share outpatient clinical data to improve patient care.

Understanding SOA
Experts are quick to point out that an SOA environment can be complex and costly to implement, a likely reason behind its relative obscurity and lack of uptake. In a nutshell, SOA is a collection of “services” that communicate with each other and enable standardized, technology-neutral data delivery.

“SOA is a way of structuring an IT system. It’s a model for encapsulating data behind well-defined services that make use of the data,” says Marc Hadley, principal engineer with the MITRE Corporation, a not-for-profit organization providing systems engineering, research and development, and IT support to the government.

SOA allows for the integration of diverse systems because IT resources—whether applications or systems—can be made available through interfaces that do not require the specific communication protocols that an operating system might.

SOA uses standard protocols and conventional interfaces that are typically provided as Web services, which allow access to data and information from diverse locations.

Pointing to the technology’s inherent benefit, Hadley notes that a typical IT scenario in a healthcare environment might have multiple applications linking into one database. Changes made to the central database can have far-reaching effects on other applications. In the case of SOA, all interfaces go through a neutral service that doesn’t affect other applications.

The benefits come in the way of creating efficiencies as they relate to the development of interfaces and standards for information sharing.

“You can write a program functionality once and reuse it many times,” Bobis explains. “Your development time goes down exponentially.”

He adds that SOA also lends itself to more robust software because it has been used over and over again and is modified when needed.

“If it has been used 1,000 times, it’s more likely that the bugs have been worked out than if it is not reusable,” Bobis says.

In healthcare, Geimer says there are currently two primary focus areas for data exchange: the standardization of the content that gets exchanged and the formation of standards for connecting various IT systems. In the case of the need to standardize content, Health Level Seven International’s (HL7) clinical document architecture (CDA) has been the industry’s road map for achieving this goal.  Many industry professionals believe SOA represents an opportunity for addressing the transmission and exchange of the CDA content.

In the case of connecting systems for data exchange, Geimer points to the industry’s use of the IHE XDS Profile, a specification developed for clinical document exchange between healthcare enterprises that is based on an SOA environment.

“It’s the one [method] that’s seen the most implementations for exchanging data,” he says, pointing out that SOA is currently the preferred model for deploying CDA content. “The VA and military health system both built their gateways through XDS. It’s the closest thing out there working.”

The Promise for Healthcare
According to HL7 CTO John Quinn, SOA currently has a role in the Nationwide Health Information Network (NHIN) and could form the basis for numerous HIE efforts going forward. A set of standards, services, and policies that enable secure HIE over the Internet, the NHIN was established to provide a foundation for the exchange of data across diverse entities, within communities, and across the country, ultimately helping to achieve the goals of the HITECH Act.

“The internal glue for interaction with the NHIN by organizations will at least initially have to support ‘pushing’ data about patients and queries about needed information for patients who have unexpectedly presented themselves for care,” Quinn says, pointing to patient interactions in venues such as emergency departments. “SOA will also support address lookup, user registry, enforcement of patient privacy requests, and more.”

 Quinn adds that the use of SOA in this type of situation is presently far more likely than the adoption of this kind of architecture in a provider organization because the NHIN has a requirement to support “interorganizational” interoperability. The urgency does not yet exist for this kind of deployment in other HIT environments.

“The implementation specifications will have to be very specific, optionality will not be available, and all stated use cases will have to be thoroughly supported,” Quinn explains. “SOA will likely have a large role in the NHIN design and implementation. I suspect that in the end the access to the NHIN will also be through services that have the ability to be tested and certified.”

Industry professionals agree that SOA could have a role in EHR adoption and infrastructures that meet MU requirements in the future, but the timing is currently a bit premature. Joy Tobin, MBA, an HIT program manager in MITRE's Center for Transforming Health, points out that SOA deployments will typically be found in medium to large organizations that have their own implementation teams.

“It could, in theory, help advance EHR adoption by enhancing functionality and what it takes to integrate various systems,” she says. “If systems were SOA, they could be more easily integrated.”

Hadley points out that SOA will likely play a greater role in meeting MU requirements once the race to meet stages 2 and 3 is under way.

“Currently, stage 1 criteria are not very strict about what they mean when they refer to data exchange,” he says. “As regulations evolve, it will become more relevant.”

Geimer concurs, adding that “stage 1 criteria are very prescriptive about content but not ambitious about technology.”

SOA could also have broad applications for the sharing of data inside and outside the walls of most healthcare organizations, especially since the average hospital sports at least 100 working systems, according to Hadley.

“In theory, SOA can ease integration of systems,” he says.

For instance, with HIM, SOA provides a way to structure systems in which capabilities can be reused. Coding, implemented as a service, can be reused for billing or medical records.

Quinn notes that SOA is ripe for opportunities to support coding functions. The problem is finding vendors to support the implementation of the architecture.

Another big question going forward, according to Hadley, is what would organizations implement? Currently, there is a lack of guidance and governance around a standardized approach to SOA.

“Some more guidance is going to go a long way,” he says. “There are lots of smaller integrations going on currently.”

Challenges to Widespread Adoption
One primary challenge of SOA adoption is that vendors are not incentivized to have their systems integrate with other systems. Therefore, many EHR products do not provide a method for deploying an SOA infrastructure.

“Vendors use SOA in their current product architectures,” Quinn says. “Of course, the amount of penetration of SOA into their architectures is unlikely to be complete at best. At worst, they are still planning to get around to it.”

He points out that almost all EHR systems being deployed and adopted are vendor packages, and most customers have little knowledge of whether SOA is applied in the internal infrastructure of the EHR application.

“Very few vendors in this industry apply a rigorous approach to manage the internal product design life cycle,” Quinn notes, pointing to Epic as a leader in this area. Vendors appear to have a goal of upgrading about 10% to 15% of an internal product’s technology and architecture each year.

“But this is still a very rare practice,” Quinn says. “Some vendors are writing new applications on new technology. However, this is taking way longer than anyone expected, with 10-plus years—and still waiting in some cases—between the time of starting a rewrite project to delivery of the new products at scale.”

Because of this nuance, Quinn believes SOA by itself will have no effect on the majority of EHR implementations, which are primarily taking place at single or small group practices that have absolutely no IT infrastructure or support staff. Since there are more than 500,000 physicians in the United States—the majority of which are in individual or small group practices—most are looking for solutions that can be taken out of the box, plugged into the Internet, and run on their own, he adds.

Geimer agrees, adding that most SOA implementations are currently for high-end projects, primarily due to the fact that they are complex and costly to deploy. While CDA for standardization of content works well in both high- and low-end environments, there currently is no option available that works well for connectivity and the retrieval of low-end data.

“SOA doesn’t address the low-end need, lack of infrastructure, or the time to set it up,” he says. “Finding a way to get low-end data retrievable and electronic—that’s what needs to happen in healthcare.”

— Selena Chavis is a Florida-based freelance journalist whose writing appears regularly in various trade and consumer publications covering everything from corporate and managerial topics to healthcare and travel.