Shift in thinking
It's precisely the diversity of IT infrastructure that makes a hospital an ideal setting for SOAs. Not only is the environment strewn with proprietary and legacy systems, but the hospital workflow also requires a nimble software architecture to keep data moving smoothly around the enterprise, says Chang.
"Traditional software capabilities aren't enough, and traditional vendors can't keep up because workflow always changes in the hospital," he says. "Imaging modalities alone can change every day."
Although the actual code work to develop Web services isn't difficult, switching to an SOA makes business process analysis crucial, Thomson at the UNC Health Care System says.
"Web services get rid of a lot of the complicated work. The XML piece itself was one of the simplest parts for us to develop. It was much more difficult to work out the business side," he says. "It's very important to know the structure of the XML document. You have to ask the right questions to decide things like what the data structure is, or the format of exchange for a medication list."
In small institutions, where both funding and staffing resources are in short supply, the mapping of business processes is important, adds Gartner's Runyon. "Understanding the business requirements is what's difficult. Anyone can write a Web service. But you have to also ask things like, 'Is it properly abstracted?' Moving forward, hospitals will think about integration beforehand. Now, the [electronic medical record] is going to require well-thought-out business issues, both semantically and syntactically. It's a whole other architectural dilemma," he says.
And Web services will become an integral part of the IT planning process because the work of developing custom interfaces for every vendor will be eliminated, say hospital IT managers.
"Much of whether or not to implement Web services boils down to strategy. What organizations with SOAs are doing is putting together the muscle that will broker data from several disparate systems with or without the HL7 limitations," says Scott Ogawa, chief technology officer at Children's Hospital Boston.
The hospital plans to use Web services to exchange data with its external partners in Massachusetts SHARE (Simplifying Healthcare Among Regional Entities), a regional collaborative initiative for data exchange operated by the Massachusetts Health Data Consortium. But Ogawa also sees the potential for the technology inside the organization.
"On the clinical side of things, we're looking for ways to not have to tie systems together using custom interfaces, but rather integrating them with Web services such that we don't have to build broker solutions."
Taking the pain out of integration
Ohio State University Medical Center's SOA-based patient-tracking system had its origins in frustration. Many hospital software and patient-monitoring equipment products that the center was using were unable to connect to patient databases.
This connectivity is necessary for patient tracking and for adding new data to the overall electronic medical record, which draws from a variety of databases, says Furrukh Khan, director of the Collaborative for Applied Software Technology at the medical center.
"The software supplied by vendors either doesn't extract data from existing databases, or it's bound together with proprietary interfaces," says Khan. Before Web services, "you had to either write the back-end part of this type of application yourself, or write it specifically to one type of software. Now the monitoring software sends requests to the SOA in XML, and we've built in a system that includes the rules of the hospital."
With Web services, Khan says, an organization is no longer forced to settle for simple asynchronous point-to-point interfaces between applications using HL7, the industry-standard protocol for hospital data transactions.
After merging two of its member hospitals, CareGroup Healthcare System found that it might have patient records for, say, a Joe Smith on more than one hospital campus. The patient medical record systems had to be linked in order to avoid errors in patient demographic data.
Using Microsoft's .Net Framework, IT staffers developed the Record Locator Service, which automatically locates the data. The Web service enables the user to provide name, gender and date of birth to a "community utility" Web service that returns a list of all care sites that a patient has visited.
"We created a Web service that figures out where all the patient records live and, in turn, who the patients are, assuming you've wrapped all the legacy systems in Web services. It basically says 'Go fetch' across the entire institution," says John Halamka, CIO at CareGroup. "The beauty is creating an abstraction layer to divorce you from the complexity of the underlying application. You don't even have to know what the application is."
Halamka's IT staff has also developed Web services that use SOAP for a number of HL7 systems, including those that provide medication lists and problem lists, as well as "wrappers" for older laboratory, radiology and other departmental systems.
"These services are all objects that let me not only link data from different systems," says Halamka, "but also do audits and security without having to build one-off solutions for each vendor's system."
Webster is a freelance writer. He can be reached at john.s.webster@verizon.net.