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 $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.
More SOA success stories:
British Telecom delivers value-added services
Countrywide reduces redundancy
Guardian Life Insurance uses SOA to get it right
Transamerica gives partners self-service access
E-mail
Printer Friendly
Reprints
(InfoWorld) - In the litigious world we live in, deploying a unified communications platform in your enterprise could...
