Some experts say the Office of Management and Budget is not wise to emphasize a top-down approach to service-oriented architecture, as expressed in the federal enterprise architecture.
“OMB looks at its role as avoiding all duplication among systems,” said Wes Rishel, a vice president and research area director of the health care provider practice at the Gartner research firm. “That’s just wrong. It sounds good on paper, [but] it just doesn’t work.”
Federal champions of enterprise architecture, which in addition to OMB include the Government Accountability Office and CIO Council, have tried to resolve the issue by making SOA part of their mandates, said Richard Reba, director of Computer Sciences Corp.’s SOA Center of Excellence.
However, many government health services cannot take that approach. For them, “much of the budgetary control is federated among state and local governments and private industry, so there is no stick” to encourage SOA adoption, Reba said. They must instead act through consortia that cultivate voluntary consensus, such as the Health and Human Services Department’s Medicaid Information Technology Architecture initiative.
— David Essex
In the past decade, Internet technology has evolved from simple screens to Web-based applications and, more recently, Web services and components. Now the buzzword is service-oriented architecture (SOA) — not a product, standard or technology but a method for assembling Web-driven enterprises one building block at a time.
Most uses of SOA in government health care have focused on integrating stand-alone databases and applications. Indeed, experts say much of SOA’s value lies in transforming electronic medical record systems and specialized applications such as radiology information systems into active participants in health information exchanges.
In the past, enterprise application integration (EAI) software handled such efforts, but that approach was less than optimal, experts say.
“EAI was kind of chunky and batchy, such as sending [Health Level 7] messages overnight,” said Wes Rishel, a vice president and research area director of the health care provider practice at the Gartner research firm. “All of the EAI vendors in the health care space have supported this since the mid-’90s.”
EAI vendors have since adopted SOA or been acquired by companies, such as IBM and BEA Systems, that specialize in Web middleware and servers. Meanwhile, more advanced vendors of health care systems have also added SOA to their products, Rishel said.
SOA uses a common language to connect applications that adhere to Web services standards. It also promises to improve on EAI’s customized, one-to-one interfaces.
“Except in rare instances, SOA projects are done in the context of a whole bunch of legacy systems,” said Ed Horst, vice president of marketing and product strategy at AmberPoint, which makes software for monitoring SOA applications. “The advantage of SOA is cross-vendor compatibility. The fundamental standards you need to start getting benefits from SOA are already there, for the most part.”
Although SOA often starts as a back-end integration effort, its potential reaches further — to business rules, workflow and collaboration.
“What we’re really talking about is how…we connect people in the health care system,” said Dr. Robert Wah, formerly acting deputy national coordinator for health IT at the Health and Human Services Department and now chief medical officer at Computer Sciences Corp.
George Eisenberger, distinguished engineer at IBM’s health care solutions group, said the company’s SOA work has focused on modernizing the claims-processing systems of large payers such as the regional Blue Cross/Blue Shield organizations. Typically, claims are handled through front-end systems with Web services wrapped around them. Those systems are then integrated with the back-end applications that handle adjudication.
Wah said other SOA deployments will likely take the form of health information exchanges that link providers, patients and payers. “When I’m thinking of [SOA], I’m thinking of ways in and out of these exchanges,” he said. Comparing it to a medical instrument with changeable tips, he added, “the in-and-out part will be the same, but the tip will be different.”
He cited a prototype health information exchange that links Boston, Indianapolis and Mendocino, Calif. CSC built the exchange in response to a request for proposals from HHS for a national health information network. In such applications, the crucial SOA components control who can contribute and access data.
Write once, use often
Reusable software components are at the core of SOA. They eliminate the need to re-create tools that already exist and facilitate development of new applications and services by letting programmers mix components in new combinations.
“Today, when the IT system needs to change to suit business needs, it’s not one thing that needs to change,” Rishel said. “SOA is not a magic cure for that, but it does, in fact, make things better, and it has a cumulative effect.”
With SOA, rather than developing components internally, agencies can often buy them from vendors. For example, IBM recently released a set of components health care payers can use for common functions such as enrolling new members. IBM also offers a methodology for designing applications that use the components and the runtime modules for executing them.
“What you’re trying to distill is the essence of the services that will support multiple services,” Eisenberger said.
Some health care applications combine SOA’s integration and development benefits. Rishel recently completed a case study of a Duke University Medical Center project to give caregivers and patients access to data from five clinical systems via a new Web portal.
Using SOA, developers took just 14 weeks to build the portal, integrate the back-end systems and install the necessary security. They also wrote an application to make it easier for clinical staff to follow up on requests.
Rishel said Duke did a good job of combining an organization’s practical needs with the SOA ideal of creating a single source for information. The single source was patient data, but it wasn’t necessary to create a new repository or choose an existing source as a standard. Rather, developers used SOA to collect data from existing systems and make it accessible in one place.
Unfortunately, many organizations neglect to create governance strategies for their SOA-based systems. Experts say that is a big oversight because as reusable components — many written by outside programmers — proliferate, security and the reliability of transactions can decrease. Such situations make it easy for a rogue service to falsely claim it has authorization to view a patient record, for example.
Michael Crooks, a senior associate at Booz Allen Hamilton, identified two main areas requiring governance policies: design and runtime. Strategies for design governance are more important, and their absence is the main reason SOA projects fail.
“You can catch issues around interoperability and compatibility of services,” he said. “Governance ensures that different services will be able to talk to each other.”
SOA run amok
Having an inadequate governance plan can result in “SOA run amok,” Eisenberger added.
Several experts also cautioned against building a huge, monolithic SOA application. Instead, they advised organizations to look for components that do a few tasks well, such as handling authentication for smart cards that many systems can use. Horst recommended making sure the organization’s development team includes people with experience building distributed, object-oriented applications rather than large, database-centric programs that rely on a single source code.
Crooks said he advises against mandating SOA use or relying completely on a bottom-up initiative. Instead, he recommended a hybrid approach that uses management sponsorship to encourage the development and sharing of components and know-how.
“Tell people to come together and select a bottom-up candidate,” Crooks said. “I hear from people who say we’re going to go bottom-up, and they have no sponsorship. [But] the ones who have their ears to the floor are the ones who can hear the train coming. If you go for the quick win, you get sponsorship across all stakeholders.”
From the battlefield to the home front: Managing medical data
Government Health IT presents Col. Claude Hines Jr., program manager for the Defense Health Information Management System, in this recent InSight eSeminar. Col. Hines discusses the health information technology and tactical challenges faced by the military medical community in Iraq, Afghanistan and other areas of conflict. In doing so, he describes the current information technology solutions for transferring clinical data between battlefield care givers to health care personnel at military treatment facilities worldwide.
