Many organizations are looking to SOA to tie together systems within the enterprise or among partners. But few face the diversity and complexity that the state of Massachusetts did when it tried to connect independent insurer, hospital, and physician systems with one another -- and with the state?s own systems for care, reimbursement, and billing.
?How do you craft enterpriselike functionality across hundreds of moving parts that don?t interoperate with each other?? was the question the state faced in 1997, recalls Harvard Medical School CIO Dr. John Halamka, who spearheaded the effort. Because the Health Insurance Portability and Accountability Act of 1998 required that every doctor, hospital, and insurer be able to exchange data for transactions, doing nothing was not an option.
The state?s major hospitals and insurers examined three options. The first was to deploy a common platform and to require insurers, hospitals, and physicians who had business with the state to implement and use it. This option, however, was too complex to pursue seriously, Halamka says.
The second option was to create a unified database for patient medical, billing, and insurance data that participants could access using their own systems. That solution would have cost US$50 million, Halamka recalls. But the third option -- to implement an SOA that would provide the data and application translation necessary for various services to interoperate without changing their code or data structures -- was viable and ended up costing just $1 million.
What Halamka calls a ?Napster for health care? has also reduced the cost per transaction from $5 to 25 cents. The system now handles approximately 9 million transactions per month. To manage this network, a group of medical associations and insurers set up a nonprofit organization called the New England Healthcare EDI Network (NEHEN). Funded by the hospitals and insurers, it has one common program management officer and an annual budget of $3 million. The result is a ?closed-loop system? that ensures accurate data and validates procedures, coverage, and billing up front, thereby reducing management costs for all participants across the state. For example, ?insurance companies save money by not having [to hire as much] staff to deny claims,? Halamka says.
Architecturally, the NEHEN system leaves data structures and applications alone, even if they are fragmented in different locations or in different systems. ?The big win is not having to rewrite old code,? Halamka says, noting that some systems date from the 1970s. The system does, however, provide a central exchange that translates data structures from one system?s format and standards to another?s, and it maps specific transaction services from one system to another, aggregating multiple service requests and using multiple databases when necessary. ?The data and the services are very disassociated,? Halamka notes. ?But it doesn?t matter whether they all sit in one place, as long as the doctor gets it all in a timely fashion.?
From a tactical perspective, as long as the system providing the data or service can communicate through TCP/IP, ?that?s all I need,? Halamka says, noting that most of the Web services in the network were developed using Microsoft .Net, with the gateways written in Visual C++ and deployed on IIS.
Strategically, the keys have been to define the business processes along with the architecture, to understand what the data means in its various repositories, and to know what applications provide what services so that middleware can be configured to make the appropriate calls and translations. ?I have the ability to control the business logic without having to modify the underlying application,? Halamka says. ?The middleware approach is very nonintrusive to the [individual organization?s] IT agenda.?
For example, patient IDs vary widely from institution to institution. Rather than require a common identifier for each patient, the NEHEN system uses a probabilistic service to check a variety of attributes -- name, nicknames (such as Johnny and Jack for John), ZIP code, gender, Social Security number, insurer, and physician -- and then maps patients? identities across systems. In the event that a new identifier class, such as employer ID, is used in identifying patients, the service can easily be modified to account for that, Halamka says. None of the other systems is affected or even aware of the change to the middleware, although system owners can decide whether they want their systems to use this new identifier class.
Because SOAP had not yet been developed and XML was not widely deployed, the NEHEN system initially used HTML as the common vehicle for data exchange. ?In the pre-XML era, we had to use the Web for content rather than the semantic Web [XML] for data. So we used simple server-side COM components to fetch HTML pages from various hospitals and display them in a unified clinical viewer that we built,? recalls Halamka, who wrote the code for this system. ?It was not elegant since we had little control over the look and feel for the HTML content returned from each hospital system, but it worked. Today, with XML and XSLT [XSL Transformation] we can treat the content as data and format it as we like.?
To ease adoption, NEHEN provides a Windows XP and Windows Server 2003 Web services suite that organizations can deploy to gain the required connectivity. For individual doctors, NEHEN provides a Web application that they can access either directly or through standard medical management applications, which vendors have modified to support the NEHEN system. In both cases, the underlying SOAP layer handles the communication to billing systems, medical records systems, and so forth. NEHEN may not be the answer to health care?s ills, but it?s eliminating lots of wasted motion in the Massachusetts system.
Galen Gruman is a San Francisco-based freelance writer.