SOA, Web services better health services
- 28 July, 2005 15:20
Hospital IT infrastructures form a complex transactional environment in which pulling applications and information together can be not just mission-critical, but also a matter of life and death.
Entrenched proprietary systems store patients' clinical, radiological, demographic and billing information as text, images and voice-annotated reports. That information must be dealt with in accordance with strict clinical priorities and federal regulations. An increasing number of health care organisations are using Web services and service-oriented architectures to make critical connections in their information systems.
"We are building SOAs and Web services that will not only integrate different systems, but also take care of the hospital's rules -- a heart operation cannot be performed on the second floor, or anesthesia equipment cannot be located in the cafeteria, for example," says Furrukh Khan, director of the Collaborative for Applied Software Technology at Ohio State University Medical Center in Columbus.
Khan and his staff have developed a Microsoft .Net-based SOA that includes Web services for connecting hospital monitoring equipment to back-end databases. Since .Net licenses were already in place, the Web services were developed for very little cost, Khan explains.
Using Microsoft Indigo and Microsoft Web Services Enhancements for .Net, which provide standards-based security and other features to the Visual Studio .Net and .Net frameworks, Khan and his staff have linked anesthesia systems with the hospital's location services, which are stored in a McKesson hospital information system. As a result, physicians and other authorised users can view a patient's picture and vital signs remotely on a Web browser, says Khan.
Without Web services, the task of integrating patient data in the clinical and departmental systems scattered throughout hospital facilities has been monumental, say hospital CIOs.
"I have clinical software from 17 vendors. All you're really trying to do is service the organization and doctors, but it's a terrible struggle to get information between the different electronic environments," says John Wade, vice president and CIO at Saint Luke's Health System.
Saint Luke's uses systems from multiple hospital software vendors, and even with in-house programming staff and funds at his disposal for integration projects, Wade says it's still very difficult to get information from one electronic environment to another.
For example, the hospital has developed a custom XML-based application for its Web portal. Called Post-It Note, the application translates Dictaphone voice into data to allow physicians to view and annotate a radiologist's voice-based report on a Web browser. The patient data resides in a system from San Francisco-based McKesson. The use of XML has made the application a service that's accessible to a variety of systems, says Wade.
Part of the difficulty in making information available to multiple systems has been the need to comply with entrenched hospital data-transaction standards such as the Health Level 7 protocol. HL7 is used for interdepartmental patient-data transactions among clinical systems, including hospital information systems and radiology, laboratory and cardiology systems. However, custom programming has often been required to integrate hospital systems that use HL7 with systems that don't use the protocol -- essentially any software that's not health-care-specific, including reporting and billing applications. As a result, hospitals can have hundreds of HL7 interfaces among systems that trade basic patient data, according to hospital IT officials.
Hospital enterprise application vendors have had to provide interfaces and consulting services to their customers to ensure that all systems work together. However, this is cumbersome and isn't achieving true integration, according to Barry Runyon, an analyst at Gartner Inc. in Stamford, Conn.
"Hospitals are a heterogeneous environment with regard to platforms and applications, and by passing around HL7 to 10 different systems, they don't integrate; they interface," says Runyon. "Integration is far more intimate and requires knowledge of workflow, as well as a security model and other specifications."
More difficulty has arisen because vendors have been slow to relinquish their captured customer bases by making their applications easier to integrate with competing systems. Even when two systems support HL7, IT staffers have had to create custom interfaces to make them work together.
"Hospital system vendors don't play well with others," says Ken Thomson, chief architect at the University of North Carolina Health Care System in Chapel Hill. "If you want to integrate their software with lots of other systems, you're out of luck. We developed our own XML-based facades to their applications. They're starting to realise they're never going to own the space. In the end, the customer will be the 800-pound gorilla that changes this, because they need direct access to those applications."
At Boston-based CareGroup Healthcare System, Web services technology has provided an efficient means of making diverse systems work together, says John Halamka, CIO of the four-hospital network. Using development products that were already in place, Halamka's staff built an XML-based application called CareWeb to link 12,000 users on 146 internal clinical information systems -- including laboratory, radiology and pharmacy systems -- across the organisation.
"Web services are the glue that you can use to create a virtual system," says Halamka, who's also a Computerworld columnist. "If you want to achieve seamless data integration, you can make your infrastructure one gigantic system or, cheaper and faster, you can use Web services."
Health care has lagged behind other industries in implementing SOAs, for both budgetary and historic reasons. IT budgets in the sector are a fraction of those in other industries. To make matters worse, HL7 didn't include XML support until this past May. Moreover, the industry groups behind Integrating the Healthcare Enterprise (IHE), a 7-year-old project of the Healthcare Information and Management Systems Society and the Radiology Society of North America, are just now planning to include XML schemas in the framework.
Page Break
Waiting for standards
IHE officials say they have been waiting for standards bodies such as the World Wide Web Consortium and the Organization for the Advancement of Structured Information Standards to settle on security, identity, manageability and other issues before including full-blown Web services definitions in its framework.
"Even though there is no current work being done within IHE, Web services are in our road-map vision. The key issue is the lack of mature health care standards specifications for Web services," says Glen Marshall, co-chairman of the IHE's infrastructure planning committee and IT architect at Siemens Medical Solutions.
For their part, vendors say they're working on the problem as their customers' IT infrastructures grow more complex and the need increases for customisable XML interfaces that support hospital workflow models.
"With Web services, we're giving our customers a more predictable, reliable means to integrate our software without needing programmers to do the heavy lifting," says Michael Solomon, chief architect at IDX Systems. "This requires an investment by the vendors, who have to figure out how to 'expose' their applications, and that's not easy to do, either culturally or philosophically."
As it stands, hospitals are forced to rely on only a few vendors -- usually no more than two or three -- to ensure that their systems work together. But even then, maintaining application interfaces is a burden on IT staffers.
"Early on, we standardized our applications as part of the selection process to make sure they integrate with each other, and they're all vendor-supported. But we still have dedicated IT people for managing the traditional interfaces," says Nancy Barrett, director of information systems integration and development for the Lifespan health system.
Hospital IT departments that are beginning to deploy Web services in an SOA have found that the technology not only eases integration between disparate systems but can also help them customise applications to the specific needs of their users.
"The whole one-size-fits-all vendor model is flawed," says Paul Chang, director of radiology at the University of Pittsburgh Medical Center. "The user should be able to create the view they need of the application they're using. A true Web services and SOA model is so promising because I can provide optimised tools to our users without reinventing the wheel. Software should bend to the will of the user, not the other way around."
Whether an organisation uses Microsoft's .Net or Java systems from IBM, BEA Systems, Oracle and others -- or both -- chances are that it has programmers with the skills needed to develop Web services, says Chang. Established Web services standards such as Simple Object Access Protocol (SOAP) and Web Services Description Language (WSDL), along with more recent standards that govern security and reliability, give IT managers enormous flexibility, he says.
"Our IT lab is split down the middle between programmers who use .Net and those who use Java. I can be completely agnostic. The Web service can be half Java and half .Net. Even Microsoft and IBM will tell you it all works together," Chang says.
New Web services standards make hospital implementations of SOAs possible, says Ohio State's Khan. "Until recently, there were no standards for security, reliable messaging or transactions. SOAP and WSDL were just the starting point. You could discover and talk to each other's applications, but you had to do things like security yourself, which makes that part of the service proprietary," he says.
Page Break
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.