Massachusetts takes a spoonful of SOA

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.

Click for larger view.

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.”